Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Mark Nottingham]

WFM. Thanks, Peter.

On 02/03/2012, at 4:50 AM, Peter Saint-Andre wrote:

> 
> 
> On 2/21/12 11:10 AM, IESG Secretary wrote:
>> A modified charter has been submitted for the Hypertext Transfer 
>> Protocol Bis (httpbis) working group in the Applications Area of the 
>> IETF.  The IESG has not made any determination as yet.  The modified 
>> charter is provided below for informational purposes only.  Please send 
>> your comments to the IESG mailing list (i...@ietf.org) by Tuesday, 
>> February 28, 2012.
> 
> Clearly this rechartering request has triggered a lengthy discussion
> about web authentication. However, the only comment on the charter
> itself Stephen Farrell's noting that this bullet is a bit vague
> (specifically that it does not mention authentication):
> 
>> * Reflecting modern security requirements and practices
> 
> Stephen and I just had a chat about this matter. He and I came up with a
> proposed paragraph to add after that list of bullet points:
> 
>   In the initial phase of work on HTTP/2.0, new proposals
>   for authentication schemes can be made.  The WG will
>   select zero or more of those with a goal of choosing
>   at least one scheme that is better than those available
>   for HTTP/1.x.  Non-selected schemes might be discussed
>   with the IETF Security Area for further work there.
> 
> Your comments are welcome.
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 

--
Mark Nottingham   http://www.mnot.net/



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Paul Hoffman]

On Mar 1, 2012, at 10:05 AM, SM wrote:

> At 09:50 01-03-2012, Peter Saint-Andre wrote:
>> Stephen and I just had a chat about this matter. He and I came up with a
>> proposed paragraph to add after that list of bullet points:
>> 
>>   In the initial phase of work on HTTP/2.0, new proposals
>>   for authentication schemes can be made.  The WG will
>>   select zero or more of those with a goal of choosing
>>   at least one scheme that is better than those available
>>   for HTTP/1.x.  Non-selected schemes might be discussed
>>   with the IETF Security Area for further work there.
> 
> If the WG selects zero, how can it meet the goal of choosing at least one 
> scheme?


It doesn't, of course. If the WG doesn't meet that goal, it will be clear at 
the time, and the WG can ask to recharter for that limited purpose.

--Paul Hoffman

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Paul Hoffman]

On Mar 1, 2012, at 10:01 AM, Nick Hilliard wrote:

> Can I suggest you also include authorization capabilities as a core
> component of this. It's not much use to have people able to authenticate
> themselves to a system if that system doesn't also provide a framework for
> allowing the server-side application decide what they can or cannot do.


This is a request for an HTTP capability that is significantly different than 
what has been proposed before, and has not been one of the items that caused 
problems in HTTP 1.x. I suggest that this not be part of the charter for 
httpbis until it can be shown to be a significant need, not just a new idea.

--Paul Hoffman

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Peter Saint-Andre]

[ no hat ]

On 3/1/12 11:01 AM, Nick Hilliard wrote:
> On 01/03/2012 17:50, Peter Saint-Andre wrote:
>> Stephen and I just had a chat about this matter. He and I came up with a
>> proposed paragraph to add after that list of bullet points:
>>
>>In the initial phase of work on HTTP/2.0, new proposals
>>for authentication schemes can be made.  The WG will
>>select zero or more of those with a goal of choosing
>>at least one scheme that is better than those available
>>for HTTP/1.x.  Non-selected schemes might be discussed
>>with the IETF Security Area for further work there.
>>
>> Your comments are welcome.
> 
> Can I suggest you also include authorization capabilities as a core
> component of this. It's not much use to have people able to authenticate
> themselves to a system if that system doesn't also provide a framework for
> allowing the server-side application decide what they can or cannot do.

Feel free to include that in your proposal. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Peter Saint-Andre]

On 3/1/12 11:05 AM, SM wrote:
> At 09:50 01-03-2012, Peter Saint-Andre wrote:
>> Stephen and I just had a chat about this matter. He and I came up with a
>> proposed paragraph to add after that list of bullet points:
>>
>>In the initial phase of work on HTTP/2.0, new proposals
>>for authentication schemes can be made.  The WG will
>>select zero or more of those with a goal of choosing
>>at least one scheme that is better than those available
>>for HTTP/1.x.  Non-selected schemes might be discussed
>>with the IETF Security Area for further work there.
> 
> If the WG selects zero, how can it meet the goal of choosing at least
> one scheme?

One can have a goal of choosing a scheme that's better, but if no one
proposes any or none of the selected schemes are deemed better, then we
will not achieve the goal. Perhaps that thought could be worded more
clearly.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[SM]

At 09:50 01-03-2012, Peter Saint-Andre wrote:

Stephen and I just had a chat about this matter. He and I came up with a
proposed paragraph to add after that list of bullet points:

   In the initial phase of work on HTTP/2.0, new proposals
   for authentication schemes can be made.  The WG will
   select zero or more of those with a goal of choosing
   at least one scheme that is better than those available
   for HTTP/1.x.  Non-selected schemes might be discussed
   with the IETF Security Area for further work there.


If the WG selects zero, how can it meet the goal of choosing at least 
one scheme?


Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Nick Hilliard]

On 01/03/2012 17:50, Peter Saint-Andre wrote:
> Stephen and I just had a chat about this matter. He and I came up with a
> proposed paragraph to add after that list of bullet points:
> 
>In the initial phase of work on HTTP/2.0, new proposals
>for authentication schemes can be made.  The WG will
>select zero or more of those with a goal of choosing
>at least one scheme that is better than those available
>for HTTP/1.x.  Non-selected schemes might be discussed
>with the IETF Security Area for further work there.
> 
> Your comments are welcome.

Can I suggest you also include authorization capabilities as a core
component of this. It's not much use to have people able to authenticate
themselves to a system if that system doesn't also provide a framework for
allowing the server-side application decide what they can or cannot do.

Nick
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Tim Bray]

+1

On Thu, Mar 1, 2012 at 9:50 AM, Peter Saint-Andre  wrote:
> 
>
> On 2/21/12 11:10 AM, IESG Secretary wrote:
>> A modified charter has been submitted for the Hypertext Transfer
>> Protocol Bis (httpbis) working group in the Applications Area of the
>> IETF.  The IESG has not made any determination as yet.  The modified
>> charter is provided below for informational purposes only.  Please send
>> your comments to the IESG mailing list (i...@ietf.org) by Tuesday,
>> February 28, 2012.
>
> Clearly this rechartering request has triggered a lengthy discussion
> about web authentication. However, the only comment on the charter
> itself Stephen Farrell's noting that this bullet is a bit vague
> (specifically that it does not mention authentication):
>
>> * Reflecting modern security requirements and practices
>
> Stephen and I just had a chat about this matter. He and I came up with a
> proposed paragraph to add after that list of bullet points:
>
>   In the initial phase of work on HTTP/2.0, new proposals
>   for authentication schemes can be made.  The WG will
>   select zero or more of those with a goal of choosing
>   at least one scheme that is better than those available
>   for HTTP/1.x.  Non-selected schemes might be discussed
>   with the IETF Security Area for further work there.
>
> Your comments are welcome.
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Peter Saint-Andre]

On 2/21/12 11:10 AM, IESG Secretary wrote:
> A modified charter has been submitted for the Hypertext Transfer 
> Protocol Bis (httpbis) working group in the Applications Area of the 
> IETF.  The IESG has not made any determination as yet.  The modified 
> charter is provided below for informational purposes only.  Please send 
> your comments to the IESG mailing list (i...@ietf.org) by Tuesday, 
> February 28, 2012.

Clearly this rechartering request has triggered a lengthy discussion
about web authentication. However, the only comment on the charter
itself Stephen Farrell's noting that this bullet is a bit vague
(specifically that it does not mention authentication):

> * Reflecting modern security requirements and practices

Stephen and I just had a chat about this matter. He and I came up with a
proposed paragraph to add after that list of bullet points:

   In the initial phase of work on HTTP/2.0, new proposals
   for authentication schemes can be made.  The WG will
   select zero or more of those with a goal of choosing
   at least one scheme that is better than those available
   for HTTP/1.x.  Non-selected schemes might be discussed
   with the IETF Security Area for further work there.

Your comments are welcome.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Henrik Nordström]

lör 2012-02-25 klockan 19:23 +0100 skrev Julian Reschke:
> Well, I'm one of the editors of the authentication framework spec, so if 
> there's something wrong with it, I'd like to know.

Only the thing said earluer

- Define how servers may influence the visible appearance of the login
action

- Perhaps some way of triggering a logout.

> So if we collectively think that the framework probably is ok, and that 
> we *do* need a new authentication scheme, what's stopping us to start 
> that activity *right now*?

Nothing.

A cleaned up http digest with less fancy bells no one implements
correctly and stronger methods would do nicely at improving the raw
security side of things.

But at the same time it alone does solve the reasons why HTTP Digest is
not widely used today which is or any of the newer use cases with auth
delegation via trusted third parties.

A very interesting thought is to look into how for example Kerberos
could be implemented as a first class HTTP Auth citizen without
violating HTTP messaging semantics. Is there anything needed at the
framework side for making that work right?

Regards
Henrik

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Henrik Nordström]

lör 2012-02-25 klockan 17:44 + skrev Stephen Farrell:

> I don't think fixing or changing the framework will give us better
> auth schemes by itself. (Better auth schemes may or may not require
> changes to the framework, I dunno.)

Obviously not. Fixing the framework giving better use of auth schemes
may triggering interest in finding a better auth scheme however.

Regards
Henrik

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Henrik Nordström]

lör 2012-02-25 klockan 14:13 + skrev Stephen Farrell:

> I don't agree with you there - the perceived low probability that
> something will be deployed is a real disincentive here. We have had
> people wanting to do work on this and have been told there's no point
> because it won't get adopted.

I do not agree that getting new auth schemes deployed if they do make
sense is such big problem in the longer scope.

We have already had two new auth schemes deployed within HTTP/1.1 during
the lifetime of HTTP/1.1 and which is in wide scale use today across
numerous different implementations. And these doesn't even followin HTTP
semantics...

A beauty of HTTP auth model here is that it can downgrade nicely,
allowing old clients to continue working only not gaining the benefits
of the new auth model. But that obviously have security implications as
well if newer user-agents can be fooled into downgrading.

Regards
Henrik

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Henrik Nordström]

tis 2012-02-21 klockan 19:50 +0100 skrev Julian Reschke:
> Well, we have an existing authentication framework. It would be 
> interesting to find out what's missing from it.

My take is better secure authentication schemes (not plaintext password
based) which is cleanly specified to a level that implementations
actually interop properly, and the ability for site owners (and proxies)
to influence how the login process is presented to users in a safe
manner that do not collide with preceived https security or makes a mess
for matchine<->machine communication not involving humans.

The existing HTTP auth framework works in general very well for
machine<->machine. 

This said I have used HTTP Digest authentication quite successfully (but
with a number of interop workarounds) with non-tech users using the
default login box, only providing a good error response message seen if
the user cacels of fails the login.

Regards
Henrik

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Adrien de Croy]

There is one other thing I would add to auth:

Ability for a challenger to identify itself, and for a response to 
target a challenger.


Currently with chained proxies, it's not possible to reliably pass 
challenges and creds back to the client.  A proxy looking at a request 
would need to maintain state to know if it challenged the client or not.


Adding a parameter to the challenge and response which identifies the 
challenger would allow for this.


In fact it would then allow proxy and server auth to use the same 
mechanism and headers.


Adrien



On 1/03/2012 8:19 a.m., Henrik Nordström wrote:

tis 2012-02-21 klockan 19:50 +0100 skrev Julian Reschke:

Well, we have an existing authentication framework. It would be
interesting to find out what's missing from it.

My take is better secure authentication schemes (not plaintext password
based) which is cleanly specified to a level that implementations
actually interop properly, and the ability for site owners (and proxies)
to influence how the login process is presented to users in a safe
manner that do not collide with preceived https security or makes a mess
for matchine<->machine communication not involving humans.

The existing HTTP auth framework works in general very well for
machine<->machine.

This said I have used HTTP Digest authentication quite successfully (but
with a number of interop workarounds) with non-tech users using the
default login box, only providing a good error response message seen if
the user cacels of fails the login.

Regards
Henrik




--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Mark Andrews]

In message <20120226064025.gh8...@1wt.eu>, Willy Tarreau writes:
> On Fri, Feb 24, 2012 at 05:57:31PM +0100, Patrik F=E4ltstr=F6m wrote:
> > I am asking more generally why specifically this DNS issue is so stuck,
> > because I think that is unfair. We upgrade other protocols...

> 
> Because in HTTP, anybody can be anywhere. You can have client-side proxies,
> server-side gateways, load balancers, etc... everyone in this chain may or
> may not resolve, it's only a matter of configuration and architecture choic=
> e.
> There are plenty of places where clients won't access public resolvers at a=
> ll
> and rely on their proxies for this. So you can't make use of DNS to improve
> these users' experience.

Proxies can lookup SRV records.  They already lookup A and  records.
 
> Also, DNS is SW. It's fast enough to send a mail. But for HTTP
> it adds too much latency. Some people in the mobile world would like to be
> able to configure an explicit proxy on their smartphones in order to avoid
> a very expensive round trip before fetching an object : at 20 host names
> on a web page, 300 ms round trip means 6 seconds are lost to resolve these
> objects if they can't be totally parallelized.

If they can't be parallelized then you can blame the page developer.

As for SRV you can always do SRV +  + A in parallel.

> DNS suggestion is something going back and forth regularly. I think that
> people who try to push it hard only see the very simple case where users
> have a direct low-latency internet connection. The reality is much much
> different. This well reflected by the fact that in the end, after many
> proposals, it has still not been adopted !
> 
> Regards,
> Willy
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[John C Klensin]

--On Friday, February 24, 2012 17:57 +0100 Patrik Fältström
 wrote:

> 
> 
> On 24 feb 2012, at 17:43, John C Klensin 
> wrote:
> 
>> It is
>> the number of folks who, for lots of reasons, haven't upgraded
>> from operating systems, resolvers, etc., that don't support
>> newer RRTYPES.
> 
> As I said, people disagree... ;-)

> As far as I know, there is nothing in any of the operating
> systems you mention that prohibits an application to send a
> random udp packet, and because of that your application can
> include a resolver library.
> 
> What is a problem are the cases where DNS is not used at all
> at the end node, but instead other name binding/lookup
> protocols combined with a firewall policy that because of this
> can and is blocking udp+tcp/53 in various ways.

I'd suggest that there are two other problems.  One is that
per-application resolver setups pretty much prevent caching of
any flavor (possibly not an issue if one opens applications,
keeps them open for a long time, and uses different target sites
with different applications, but, if that scenario has been
studied wrt frequency, I'm not aware of it).  The other, more
important, issue is that it just about guarantees an
inconsistent user experience wrt the treatment of names.  

Of course those are tradeoffs against locally-improved
functionality and reasonable people can disagree about how
important those issues are wrt the other considerations.


> That said, I still ask when it is, in general, time to just
> move forward. I see for example many other reasons why people
> should not use that old software. IE6 for example. Yes,
> economically constrained situations exists, but that problem
> do not go away by having us not start using SRV or HTTP/1.1 or
> SNI or HTML5.0 or...pick your favourite. And with SPF, that is
> not used by the edge node either.
> 
> I am asking more generally why specifically this DNS issue is
> so stuck, because I think that is unfair. We upgrade other
> protocols...

Where I probably agree with you is that I think that we need to
evaluate costs, benefits, and risks and to do so against an
understanding and hope that we will have _many_ more Internet
users a decade from now than we do today.  Accepting the latter
may justify changes even more painful than transition to a new
RRTYPE if we understand that we are inconveniencing a relatively
small number of people today in order to make things much better
for a far larger future number.  And that is why I have never
believed in arguments for guaranteed absolute forward
compatibility in Internet, and Internet-like, situations.

> But my point is, people disagree. As we see here ;-)

Indeed.  Even though I would hope that we can at least mostly
agree about the facts even if we disagree about the tradeoffs to
which they lead.

john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Willy Tarreau]

On Fri, Feb 24, 2012 at 05:57:31PM +0100, Patrik Fältström wrote:
> I am asking more generally why specifically this DNS issue is so stuck,
> because I think that is unfair. We upgrade other protocols...

Because in HTTP, anybody can be anywhere. You can have client-side proxies,
server-side gateways, load balancers, etc... everyone in this chain may or
may not resolve, it's only a matter of configuration and architecture choice.
There are plenty of places where clients won't access public resolvers at all
and rely on their proxies for this. So you can't make use of DNS to improve
these users' experience.

Also, DNS is SW. It's fast enough to send a mail. But for HTTP
it adds too much latency. Some people in the mobile world would like to be
able to configure an explicit proxy on their smartphones in order to avoid
a very expensive round trip before fetching an object : at 20 host names
on a web page, 300 ms round trip means 6 seconds are lost to resolve these
objects if they can't be totally parallelized.

DNS suggestion is something going back and forth regularly. I think that
people who try to push it hard only see the very simple case where users
have a direct low-latency internet connection. The reality is much much
different. This well reflected by the fact that in the end, after many
proposals, it has still not been adopted !

Regards,
Willy

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Willy Tarreau]

Hi Adrien,

On Sun, Feb 26, 2012 at 02:54:01PM +1300, Adrien de Croy wrote:
> 
> I wonder if it would be helpful for people to outline what they expect 
> are the issues to be solved by doing more work on an HTTP auth mechanism.
> 
> I get the feeling that some think the scope would encompass providing 
> auth support for web applications, whereas others are mainly concerned 
> with the transport level auth.

I am personally concerned with the risk that new auth schemes continue
to mix messages and transport. I don't think we need to define these new
schemes, we just need to ensure the new protocol offers provision for
doing the things right. I'd like to ensure we never get a new NTLM-like
design error which forces every implementation to break the HTTP model
to try to be compatible.

Also, (that's not directly related to auth) it would be nice if we could
have a random session ID in messages that browsers would send to help the
whole intermediary chain select the appropriate server. A simple hash on
this session ID would make load balancing much easier and much more reliable
than any other algorithm right now and would definitely help when challenge
based auth schemes are needed.

(...)
> If we're just talking about transport auth, then what's wrong with 
> something like kerberos.  As for server logging a client out, the auth 
> mechanism would need a token that can be revoked by the server, since 
> one cannot rely on client co-operation in such a matter.  A kerberos 
> ticket seems to fit this bill.  then we'd just need a mechanism for a 
> client to request revokation (logout).  It is also AFAIK supported on 
> all server platforms, unlike any auth mechanism that requires access to 
> plaintext passwords at the server end - these are not always available.

It is comparable to what is already done with cookies in most applications
(ie I have nothing against this). We just have to keep in mind that auth
methods will change with time. Many applications right now expect two-factor
auth and/or some complex UI adaptations to protect against malware. That's
why I think that our work on supporting auth should mainly ensure we offer
the solid blocks for building new auth schemes and don't necessarily need
to define these schemes ourselves.

Regards,
Willy

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Adrien de Croy]

I wonder if it would be helpful for people to outline what they expect 
are the issues to be solved by doing more work on an HTTP auth mechanism.


I get the feeling that some think the scope would encompass providing 
auth support for web applications, whereas others are mainly concerned 
with the transport level auth.


IMO http auth is not particularly suited to solve the issues required 
for web site authors, for the simple issue of administrative boundaries 
and realms of accounts.


For example the web server that sits on an OS that has 1 user database, 
yet hosts 10 web sites each of which require their own independent user 
database, and require the ability to create and destroy accounts, and 
these accounts NOT be OS ones (i.e. not grant any access to the OS).  
Sure these issues could be engineered around, but it would add to the 
current scope (for change) every web application that currently manages 
accounts (a great deal of them).


If we're just talking about transport auth, then what's wrong with 
something like kerberos.  As for server logging a client out, the auth 
mechanism would need a token that can be revoked by the server, since 
one cannot rely on client co-operation in such a matter.  A kerberos 
ticket seems to fit this bill.  then we'd just need a mechanism for a 
client to request revokation (logout).  It is also AFAIK supported on 
all server platforms, unlike any auth mechanism that requires access to 
plaintext passwords at the server end - these are not always available.


Adrien


On 26/02/2012 3:03 a.m., Julian Reschke wrote:

On 2012-02-25 14:46, Stephen Farrell wrote:

...
Yeah that's a tricky one. While one might like to
see "one or more" in both places that might not be
practical.

In the proposal above the goal is that httpbis pick one
or more but recognising the reality that we might not get
a new proposal that httpbis will accept and that folks
will really implement and deploy.

So:
Goal = one or more
Reluctant recognition of reality = zero or more

With this plan if httpbis in fact select zero new proposals
that would represent a failure for all concerned. The "zero
or more" term is absolutely not intended to provide a way to
just punt on the question.

Such a failure at the point where httpbis was re-chartering
to work on a HTTP/2.0 selection with no better security than
we now have is probably better evaluated as a whole - I
guess the question for the IETF/IESG at that point would
be whether the Internet would be better with or without
such a beast, or better waiting a while until the security
thing did get fixed.

I can imagine an argument might ensue about that;-)
...


If we just need a new authentication scheme, nothing stops people from 
working on that right now. I don't see how that should affect HTTP/2.0.


If the "right" way to do security needs changes in the HTTP/1.1 
authentication framework, then we should fix/augment/tune HTTP/1.1. 
It's not going to go away anytime soon.


Best regards, Julian



--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Patrik Fältström]

On 24 feb 2012, at 17:43, John C Klensin  wrote:

> It is
> the number of folks who, for lots of reasons, haven't upgraded
> from operating systems, resolvers, etc., that don't support
> newer RRTYPES.

As I said, people disagree... ;-)

As far as I know, there is nothing in any of the operating systems you mention 
that prohibits an application to send a random udp packet, and because of that 
your application can include a resolver library.

What is a problem are the cases where DNS is not used at all at the end node, 
but instead other name binding/lookup protocols combined with a firewall policy 
that because of this can and is blocking udp+tcp/53 in various ways.

That said, I still ask when it is, in general, time to just move forward. I see 
for example many other reasons why people should not use that old software. IE6 
for example. Yes, economically constrained situations exists, but that problem 
do not go away by having us not start using SRV or HTTP/1.1 or SNI or HTML5.0 
or...pick your favourite. And with SPF, that is not used by the edge node 
either.

I am asking more generally why specifically this DNS issue is so stuck, because 
I think that is unfair. We upgrade other protocols...

But my point is, people disagree. As we see here ;-)

   Patrik

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Stephen Farrell]

On 02/26/2012 01:54 AM, Mark Nottingham wrote:


On 26/02/2012, at 12:32 PM, Stephen Farrell wrote:


Could you please explain why you think tying this effort to HTTP/2.0 is 
necessary to achieve that? To me that's the critical bit, and I still haven't 
seen the reasoning (perhaps I missed it).


That's a fair question that doesn't have a good and quick
answer, and some of the argument applies to the httpbis wg
and not to HTTP/2.0 per se.


Aha. If we can decouple the auth work from the HTTP/2.0 deliverable, I'm less 
concerned -- although we're going to be quite busy.

For *this* re-charter, can we only solicit proposals for auth, and make the 
decision about what/if we'll go ahead in the *next* re-charter?

I.e., I'd like to wait before we decide on both pieces (the wire protocol and 
auth) before making commitments, or even plans. Part of the selection process 
for the wire protocol is determining implementer interest, and gathering the 
same information about the auth proposals will shed a lot more light on this 
conversation, I think.


Right, that's pretty close to what I proposed.

Let's see if we hear supportive noises or howls of outrage or silence.

I think I'd suggest to keep the idea of chartering a sec wg to pick up
the pieces that httpbis doesn't want to progress, once that situation 
becomes clear. All going well, that'd result in some experimental RFCs

that could be picked up with little effort should events warrant. But
that doesn't directly impact on httpbis I guess.

S.







Caveats: this is probably something that needs more bandwidth
than mail; most of the points below were already raised by
others on this thread (though I didn't go back through all
the mail yet) and this is not in any particular ordering.


That's OK - we'll be in Paris soon.


- We've not really improved this in over a decade. Its time.


Don't disagree.


- The community's appreciation of better security has
  changed in that time as well so maybe its more tractable
  now and we've more experience of real attacks.
- Improving security after the fact is not a good plan.


Of course.


- Thinking a separate security WG could provide an answer
  that'd be adopted seems less likely to work to some. (It
  does seem more likely to work for some others admittedly.)


Yes, there are arguments on both sides.


- A backwards-incompatible change (if needed) could be
  done much more easily when changing HTTP. Its at least
  time to explore the area with that possibility in mind..


Hmm. One of the core ideas we're moving forward with is that 2.0 is 
semantically compatible with 1.x, even if it isn't syntactically.


- A scheme less susceptible to phishing that got deployed
  could be very valuable. Its not ridiculous to think that
  might require breaking backwards compatibility somehow.


Agreed, but I think that's much more about the browser UI than about the wire 
protocol.


So, a bunch of things. Maybe none individually compelling.
But arguably taken together sufficiently convincing that
not attempting again to do something here would really be
inexcusable.

And yes, I do recognise that attempting to solve this does
add some risk. Most good things do.


Absolutely.

Cheers,


--
Mark Nottingham   http://www.mnot.net/





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[TEVFİK ŞAHİN]

Zc
-Original Message-
From: Yoav Nir
Sent:  26.02.2012, 11:45
To: Mark Nottingham
Cc: The IESG; ietf-http...@w3.org Group; IETF-Discussion Discussion
Subject: Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)


On Feb 26, 2012, at 2:44 AM, Mark Nottingham wrote:

>
>>
>> I proposed a plan that I think might allow us to make progress
>> on that. I believe we could.
>
> OK, great.
>
> Could you please explain why you think tying this effort to HTTP/2.0 is 
> necessary to achieve that? To me that's the critical bit, and I still haven't 
> seen the reasoning (perhaps I missed it).

I think I have *an* answer to this, though probably not *the* answer.

There's two stages to adoption - implementation and roll-out. Obviously you 
can't roll out "new authentication" before the browsers and servers implement 
it. For my website, I wouldn't roll out new auth if only one or two of the 
browsers out there implemented it. Even if all the big ones (IE, Firefox, 
Chrome, Opera) did, I would still have to provide a backwards compatibility 
authentication scheme to support older browsers. This would lead to both 
inconsistent UI and to ugly javascript that detects the browser version, and 
makes the roll-out slower.

If any HTTP/2.0 browser is bound to have "new authentication" it makes things 
much easier.

This could be circumvented by adding request headers that advertise 
capabilities, but I don't think we like those much.

Yoav


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



“This Message (including any attachments) contains confidential information and 
is intended only for the individual named. If you are not the named adressee or 
not related with the content of this Message, you are forbidden to read, 
disseminate, distribute, copy, reproduce or modify this mail by our Company. 
Please notfy the sender immediately if you have received this e-mail by mistake 
and delete this e-mail from your system. E-mail transmisson can not be 
guaranteed to be secure or error-free as the mail may arrive late or incomplete 
or the information could be intercepted, corrupted, lost, destroyed, amended, , 
or contain viruses. The sender therefore does not accept liability for any 
errors, loss of integrity or confidentiality or ommissions in the contents of 
this Message or for the information transmission, reception, storage of use of 
such in any way whatsoever, which arise as a result of e-mail transmission. Any 
opinions expressed in this message are those of the author and may not 
necessarily reflect the opinions of Our Company.

Copyright in documents created by or on behalf of our Company remains vested in 
us, and we assert all of our moral and intellectual property rights.”


“Bu mesaj (ve ekleri) gizli bilgi içermektedir ve sadece gönderilen kişiye 
yöneliktir. Bu e-mailin muhatabı değilseniz veya içeriği ile ilginiz yoksa, 
Şirketimizin onayı olmaksızın bu mesajın okunması, değiştirilmesi, 
kopyalanması, üçüncü kişilere açıklanması, yayınlanması, ifşa edilmesi veya 
iletilmesi yasaktır. Bu mesajın gönderilmek istendiği kişi değilseniz (ya da bu 
e-posta'yı yanlışlıkla aldıysanız), lütfen yollayan kişiyi hemen haberdar 
ediniz ve mesajı sisteminizden derhal siliniz. E-mail iletiminin güvenli veya 
hatasız olduğunun garantisi olmadığından geç veya eksik iletim veya içerik ve 
bilgilerde eksiklik, kayıp, değişiklik veya virüs olabilir. Bu nedenle, bu 
mesajın iletiminden dolayı, gönderen, içerikteki hata, eksiklik, doğruluğun ve 
gizliliğin ihlalinden veya bu yolla bilgi paylaşımı, iletimi, depolanması gibi 
herhangi bir kullanımından hiçbir şekilde sorumlu değildir. Bu mesajın içeriği 
yazarına ait olup, Şirketimizin görüşlerini içermeyebilir.

Bu mesajın içeriğinde geçen Şirketimizin ad veya nanıma yaratılan fikri ve 
sınai haklar Şirketimize ait olup, maddi ve manevi tüm hakları Şirketimizde 
saklıdır.”
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Julian Reschke]

On 2012-02-26 10:44, Yoav Nir wrote:

...

Could you please explain why you think tying this effort to HTTP/2.0 is 
necessary to achieve that? To me that's the critical bit, and I still haven't 
seen the reasoning (perhaps I missed it).


I think I have *an* answer to this, though probably not *the* answer.

There's two stages to adoption - implementation and roll-out. Obviously you can't roll 
out "new authentication" before the browsers and servers implement it. For my 
website, I wouldn't roll out new auth if only one or two of the browsers out there 
implemented it. Even if all the big ones (IE, Firefox, Chrome, Opera) did, I would still 
have to provide a backwards compatibility authentication scheme to support older 
browsers. This would lead to both inconsistent UI and to ugly javascript that detects the 
browser version, and makes the roll-out slower.


You can send multiple challenges in one response.

We could also define a way to make HTML-form-based login an HTTP scheme 
(see ) to 
integrate better what people use today.



If any HTTP/2.0 browser is bound to have "new authentication" it makes things 
much easier.

This could be circumvented by adding request headers that advertise 
capabilities, but I don't think we like those much.


I don't believe we need those. If we do, we should retrofit this into 
1.1 as well.


Anyway, I see lots of theoretical discussion about process. What's 
needed is people doing the actual work, both spec-wise and 
implementation-wise. That's the critical problem.


Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Yoav Nir]

On Feb 26, 2012, at 2:44 AM, Mark Nottingham wrote:

> 
>> 
>> I proposed a plan that I think might allow us to make progress
>> on that. I believe we could.
> 
> OK, great. 
> 
> Could you please explain why you think tying this effort to HTTP/2.0 is 
> necessary to achieve that? To me that's the critical bit, and I still haven't 
> seen the reasoning (perhaps I missed it).

I think I have *an* answer to this, though probably not *the* answer.

There's two stages to adoption - implementation and roll-out. Obviously you 
can't roll out "new authentication" before the browsers and servers implement 
it. For my website, I wouldn't roll out new auth if only one or two of the 
browsers out there implemented it. Even if all the big ones (IE, Firefox, 
Chrome, Opera) did, I would still have to provide a backwards compatibility 
authentication scheme to support older browsers. This would lead to both 
inconsistent UI and to ugly javascript that detects the browser version, and 
makes the roll-out slower.

If any HTTP/2.0 browser is bound to have "new authentication" it makes things 
much easier.

This could be circumvented by adding request headers that advertise 
capabilities, but I don't think we like those much.

Yoav


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Mark Nottingham]

On 26/02/2012, at 12:32 PM, Stephen Farrell wrote:

>> Could you please explain why you think tying this effort to HTTP/2.0 is 
>> necessary to achieve that? To me that's the critical bit, and I still 
>> haven't seen the reasoning (perhaps I missed it).
> 
> That's a fair question that doesn't have a good and quick
> answer, and some of the argument applies to the httpbis wg
> and not to HTTP/2.0 per se.

Aha. If we can decouple the auth work from the HTTP/2.0 deliverable, I'm less 
concerned -- although we're going to be quite busy. 

For *this* re-charter, can we only solicit proposals for auth, and make the 
decision about what/if we'll go ahead in the *next* re-charter? 

I.e., I'd like to wait before we decide on both pieces (the wire protocol and 
auth) before making commitments, or even plans. Part of the selection process 
for the wire protocol is determining implementer interest, and gathering the 
same information about the auth proposals will shed a lot more light on this 
conversation, I think.


> Caveats: this is probably something that needs more bandwidth
> than mail; most of the points below were already raised by
> others on this thread (though I didn't go back through all
> the mail yet) and this is not in any particular ordering.

That's OK - we'll be in Paris soon.

> - We've not really improved this in over a decade. Its time.

Don't disagree.

> - The community's appreciation of better security has
>  changed in that time as well so maybe its more tractable
>  now and we've more experience of real attacks.
> - Improving security after the fact is not a good plan.

Of course.

> - Thinking a separate security WG could provide an answer
>  that'd be adopted seems less likely to work to some. (It
>  does seem more likely to work for some others admittedly.)

Yes, there are arguments on both sides.

> - A backwards-incompatible change (if needed) could be
>  done much more easily when changing HTTP. Its at least
>  time to explore the area with that possibility in mind..

Hmm. One of the core ideas we're moving forward with is that 2.0 is 
semantically compatible with 1.x, even if it isn't syntactically. 

> - A scheme less susceptible to phishing that got deployed
>  could be very valuable. Its not ridiculous to think that
>  might require breaking backwards compatibility somehow.

Agreed, but I think that's much more about the browser UI than about the wire 
protocol.

> So, a bunch of things. Maybe none individually compelling.
> But arguably taken together sufficiently convincing that
> not attempting again to do something here would really be
> inexcusable.
> 
> And yes, I do recognise that attempting to solve this does
> add some risk. Most good things do.

Absolutely.

Cheers,


--
Mark Nottingham   http://www.mnot.net/



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Stephen Farrell]

On 02/26/2012 12:44 AM, Mark Nottingham wrote:


On 26/02/2012, at 11:40 AM, Stephen Farrell wrote:



Mark,

I was going to respond blow-by-blow but there's not much
point in that, other than to say that your mail seems to
me a tad over the top.


Sorry if you think so. I'm VERY sensitive to the risks that we're undertaking 
here,


Fair 'nuff. I consider my self fairly insensitive generally
which of course means I don't care what others think about
that:-)

> and I want to be crystal-clear about what we're going to do.
> As I saw it, your path forward was a risky one.

I don't get that. I'd be interested in why it appears that way
to you and if there are ways to reduce risk but still try
make progress on security stuff.


(Maybe you misinterpreted me describing what might happen
as some kind of threat to try slow people down or something,
I don't know. I do know that I don't do that kind of thing
and if I tried I probably wouldn't be very good at it anyway;-)


It may not have been your intent; my concern was that the effect would be the 
same.


Don't get that either. I think I just pointed out the obvious
based on the proposed charter - at the point of the next proposed
re-charter, there'll be IETF/IESG review.


Anyway, I think we should focus on a way forward that attempts
progress on what we appear to agree is the desirable outcome:


They are VERY VERY VERY interested in security, as are many other
people in the broader community. If the IETF were to come up with a
viable proposal that solves their problems, they would beat down this
organisation's doors.


I proposed a plan that I think might allow us to make progress
on that. I believe we could.


OK, great.

Could you please explain why you think tying this effort to HTTP/2.0 is 
necessary to achieve that? To me that's the critical bit, and I still haven't 
seen the reasoning (perhaps I missed it).


That's a fair question that doesn't have a good and quick
answer, and some of the argument applies to the httpbis wg
and not to HTTP/2.0 per se.

Caveats: this is probably something that needs more bandwidth
than mail; most of the points below were already raised by
others on this thread (though I didn't go back through all
the mail yet) and this is not in any particular ordering.

- We've not really improved this in over a decade. Its time.
- The community's appreciation of better security has
  changed in that time as well so maybe its more tractable
  now and we've more experience of real attacks.
- Improving security after the fact is not a good plan.
- Thinking a separate security WG could provide an answer
  that'd be adopted seems less likely to work to some. (It
  does seem more likely to work for some others admittedly.)
- A backwards-incompatible change (if needed) could be
  done much more easily when changing HTTP. Its at least
  time to explore the area with that possibility in mind..
- A scheme less susceptible to phishing that got deployed
  could be very valuable. Its not ridiculous to think that
  might require breaking backwards compatibility somehow.

So, a bunch of things. Maybe none individually compelling.
But arguably taken together sufficiently convincing that
not attempting again to do something here would really be
inexcusable.

And yes, I do recognise that attempting to solve this does
add some risk. Most good things do.

S.



Thanks,




S



On 02/25/2012 11:25 PM, Mark Nottingham wrote:


On 26/02/2012, at 1:13 AM, Stephen Farrell wrote:


If we just need a new authentication scheme, nothing stops people from
working on that right now.


I don't agree with you there - the perceived low probability that
something will be deployed is a real disincentive here. We have had
people wanting to do work on this and have been told there's no point
because it won't get adopted.


Let's speak plainly here.

It's not hard for new things to be deployed -- there are lots of new things 
being deployed on the Web right now.

What IS hard is forcing browser vendors to deploy something that they don't 
think is going to work, or that they're not terribly interested in.

They are VERY VERY VERY interested in security, as are many other people in the 
broader community. If the IETF were to come up with a viable proposal that 
solves their problems, they would beat down this organisation's doors.

The IETF may have some smart people, and they may have ideas about Web 
security, but that doesn't necessarily make them into workable solutions for 
the various stakeholders. The discussion about Web security is much broader, 
involving not only the browser vendors, but also organisations like the W3C, 
IIW, etc.

Using HTTP/2.0 as a mechanism to shortcut all of this and force what people in 
the IETF think is a good solution down implementers' throats is going to lead 
to a very predictable and messy fail.



With this plan if httpbis in fact select zero new proposals
that would represent a failure for all concerned. The "zero
or more" term i

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Mark Nottingham]

On 26/02/2012, at 11:40 AM, Stephen Farrell wrote:

> 
> Mark,
> 
> I was going to respond blow-by-blow but there's not much
> point in that, other than to say that your mail seems to
> me a tad over the top.

Sorry if you think so. I'm VERY sensitive to the risks that we're undertaking 
here, and I want to be crystal-clear about what we're going to do. As I saw it, 
your path forward was a risky one.


> (Maybe you misinterpreted me describing what might happen
> as some kind of threat to try slow people down or something,
> I don't know. I do know that I don't do that kind of thing
> and if I tried I probably wouldn't be very good at it anyway;-)

It may not have been your intent; my concern was that the effect would be the 
same.


> Anyway, I think we should focus on a way forward that attempts
> progress on what we appear to agree is the desirable outcome:
> 
> > They are VERY VERY VERY interested in security, as are many other
> > people in the broader community. If the IETF were to come up with a
> > viable proposal that solves their problems, they would beat down this
> > organisation's doors.
> 
> I proposed a plan that I think might allow us to make progress
> on that. I believe we could.

OK, great. 

Could you please explain why you think tying this effort to HTTP/2.0 is 
necessary to achieve that? To me that's the critical bit, and I still haven't 
seen the reasoning (perhaps I missed it).

Thanks,


> 
> S
> 
> 
> 
> On 02/25/2012 11:25 PM, Mark Nottingham wrote:
>> 
>> On 26/02/2012, at 1:13 AM, Stephen Farrell wrote:
 
 If we just need a new authentication scheme, nothing stops people from
 working on that right now.
>>> 
>>> I don't agree with you there - the perceived low probability that
>>> something will be deployed is a real disincentive here. We have had
>>> people wanting to do work on this and have been told there's no point
>>> because it won't get adopted.
>> 
>> Let's speak plainly here.
>> 
>> It's not hard for new things to be deployed -- there are lots of new things 
>> being deployed on the Web right now.
>> 
>> What IS hard is forcing browser vendors to deploy something that they don't 
>> think is going to work, or that they're not terribly interested in.
>> 
>> They are VERY VERY VERY interested in security, as are many other people in 
>> the broader community. If the IETF were to come up with a viable proposal 
>> that solves their problems, they would beat down this organisation's doors.
>> 
>> The IETF may have some smart people, and they may have ideas about Web 
>> security, but that doesn't necessarily make them into workable solutions for 
>> the various stakeholders. The discussion about Web security is much broader, 
>> involving not only the browser vendors, but also organisations like the W3C, 
>> IIW, etc.
>> 
>> Using HTTP/2.0 as a mechanism to shortcut all of this and force what people 
>> in the IETF think is a good solution down implementers' throats is going to 
>> lead to a very predictable and messy fail.
>> 
>> 
>>> With this plan if httpbis in fact select zero new proposals
>>> that would represent a failure for all concerned. The "zero
>>> or more" term is absolutely not intended to provide a way to
>>> just punt on the question.
>> 
>> This makes me very uncomfortable. How hard and long do we have to try before 
>> we convince you that we're not punting?
>> 
>> 
>>> Such a failure at the point where httpbis was re-chartering
>>> to work on a HTTP/2.0 selection with no better security than
>>> we now have is probably better evaluated as a whole - I
>>> guess the question for the IETF/IESG at that point would
>>> be whether the Internet would be better with or without
>>> such a beast, or better waiting a while until the security
>>> thing did get fixed.
>> 
>> 
>> If we "wait a while until the security thing [does] get fixed", I'll gladly 
>> bet any amount of money you care to name that SPDY will gain market traction 
>> so quickly as to make any HTTP/2.0 effort in IETF completely 
>> backwards-looking. Refer to the debacle with Cookies for one such example.
>> 
>> So, again, I'm fine with allowing new authentication schemes to be proposed, 
>> in the off chance that some genius will suddenly propose something that 
>> meets all of the myriad requirements (that still aren't well-defined) and 
>> gets consensus and buy-in from implementers.
>> 
>> However, requiring us to output such a beast and gating HTTP/2.0 on it is 
>> effectively asking us to spin our wheels for n years. And the folks working 
>> on SPDY will - quite rightly - walk away and do their work somewhere more 
>> sane.
>> 
>> And I still don't see why it's necessary to do this all in one effort. 
>> Julian's point was that the only technical reason to combine authentication 
>> work with re-specifying HTTP is to make the new authentication scheme MTI. 
>> Otherwise, the work can be done separately. Roy has expressed interest in 
>> coming up with a new scheme that isn't 

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Stephen Farrell]

Mark,

I was going to respond blow-by-blow but there's not much
point in that, other than to say that your mail seems to
me a tad over the top.

(Maybe you misinterpreted me describing what might happen
as some kind of threat to try slow people down or something,
I don't know. I do know that I don't do that kind of thing
and if I tried I probably wouldn't be very good at it anyway;-)

Anyway, I think we should focus on a way forward that attempts
progress on what we appear to agree is the desirable outcome:

> They are VERY VERY VERY interested in security, as are many other
> people in the broader community. If the IETF were to come up with a
> viable proposal that solves their problems, they would beat down this
> organisation's doors.

I proposed a plan that I think might allow us to make progress
on that. I believe we could.

S



On 02/25/2012 11:25 PM, Mark Nottingham wrote:


On 26/02/2012, at 1:13 AM, Stephen Farrell wrote:


If we just need a new authentication scheme, nothing stops people from
working on that right now.


I don't agree with you there - the perceived low probability that
something will be deployed is a real disincentive here. We have had
people wanting to do work on this and have been told there's no point
because it won't get adopted.


Let's speak plainly here.

It's not hard for new things to be deployed -- there are lots of new things 
being deployed on the Web right now.

What IS hard is forcing browser vendors to deploy something that they don't 
think is going to work, or that they're not terribly interested in.

They are VERY VERY VERY interested in security, as are many other people in the 
broader community. If the IETF were to come up with a viable proposal that 
solves their problems, they would beat down this organisation's doors.

The IETF may have some smart people, and they may have ideas about Web 
security, but that doesn't necessarily make them into workable solutions for 
the various stakeholders. The discussion about Web security is much broader, 
involving not only the browser vendors, but also organisations like the W3C, 
IIW, etc.

Using HTTP/2.0 as a mechanism to shortcut all of this and force what people in 
the IETF think is a good solution down implementers' throats is going to lead 
to a very predictable and messy fail.



With this plan if httpbis in fact select zero new proposals
that would represent a failure for all concerned. The "zero
or more" term is absolutely not intended to provide a way to
just punt on the question.


This makes me very uncomfortable. How hard and long do we have to try before we 
convince you that we're not punting?



Such a failure at the point where httpbis was re-chartering
to work on a HTTP/2.0 selection with no better security than
we now have is probably better evaluated as a whole - I
guess the question for the IETF/IESG at that point would
be whether the Internet would be better with or without
such a beast, or better waiting a while until the security
thing did get fixed.



If we "wait a while until the security thing [does] get fixed", I'll gladly bet 
any amount of money you care to name that SPDY will gain market traction so quickly as to 
make any HTTP/2.0 effort in IETF completely backwards-looking. Refer to the debacle with 
Cookies for one such example.

So, again, I'm fine with allowing new authentication schemes to be proposed, in 
the off chance that some genius will suddenly propose something that meets all 
of the myriad requirements (that still aren't well-defined) and gets consensus 
and buy-in from implementers.

However, requiring us to output such a beast and gating HTTP/2.0 on it is 
effectively asking us to spin our wheels for n years. And the folks working on 
SPDY will - quite rightly - walk away and do their work somewhere more sane.

And I still don't see why it's necessary to do this all in one effort. Julian's 
point was that the only technical reason to combine authentication work with 
re-specifying HTTP is to make the new authentication scheme MTI. Otherwise, the 
work can be done separately. Roy has expressed interest in coming up with a new 
scheme that isn't necessarily targeted at browsers -- which is great, but I 
don't see why it has to be part of this WG.

We potentially have a LOT of work on our plate, and that work is channeling the 
energy behind a new serialisation of HTTP into something worthy of being called 
HTTP. Doing research and development on Web security is a very different kind 
of work, and the two don't mix well, IME.



--
Mark Nottingham   http://www.mnot.net/





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Mark Nottingham]

On 26/02/2012, at 1:13 AM, Stephen Farrell wrote:
>> 
>> If we just need a new authentication scheme, nothing stops people from
>> working on that right now.
> 
> I don't agree with you there - the perceived low probability that
> something will be deployed is a real disincentive here. We have had
> people wanting to do work on this and have been told there's no point
> because it won't get adopted.

Let's speak plainly here.

It's not hard for new things to be deployed -- there are lots of new things 
being deployed on the Web right now.

What IS hard is forcing browser vendors to deploy something that they don't 
think is going to work, or that they're not terribly interested in.

They are VERY VERY VERY interested in security, as are many other people in the 
broader community. If the IETF were to come up with a viable proposal that 
solves their problems, they would beat down this organisation's doors.

The IETF may have some smart people, and they may have ideas about Web 
security, but that doesn't necessarily make them into workable solutions for 
the various stakeholders. The discussion about Web security is much broader, 
involving not only the browser vendors, but also organisations like the W3C, 
IIW, etc.

Using HTTP/2.0 as a mechanism to shortcut all of this and force what people in 
the IETF think is a good solution down implementers' throats is going to lead 
to a very predictable and messy fail.


> With this plan if httpbis in fact select zero new proposals
> that would represent a failure for all concerned. The "zero
> or more" term is absolutely not intended to provide a way to
> just punt on the question.

This makes me very uncomfortable. How hard and long do we have to try before we 
convince you that we're not punting?


> Such a failure at the point where httpbis was re-chartering
> to work on a HTTP/2.0 selection with no better security than
> we now have is probably better evaluated as a whole - I
> guess the question for the IETF/IESG at that point would
> be whether the Internet would be better with or without
> such a beast, or better waiting a while until the security
> thing did get fixed.


If we "wait a while until the security thing [does] get fixed", I'll gladly bet 
any amount of money you care to name that SPDY will gain market traction so 
quickly as to make any HTTP/2.0 effort in IETF completely backwards-looking. 
Refer to the debacle with Cookies for one such example.

So, again, I'm fine with allowing new authentication schemes to be proposed, in 
the off chance that some genius will suddenly propose something that meets all 
of the myriad requirements (that still aren't well-defined) and gets consensus 
and buy-in from implementers. 

However, requiring us to output such a beast and gating HTTP/2.0 on it is 
effectively asking us to spin our wheels for n years. And the folks working on 
SPDY will - quite rightly - walk away and do their work somewhere more sane.

And I still don't see why it's necessary to do this all in one effort. Julian's 
point was that the only technical reason to combine authentication work with 
re-specifying HTTP is to make the new authentication scheme MTI. Otherwise, the 
work can be done separately. Roy has expressed interest in coming up with a new 
scheme that isn't necessarily targeted at browsers -- which is great, but I 
don't see why it has to be part of this WG.

We potentially have a LOT of work on our plate, and that work is channeling the 
energy behind a new serialisation of HTTP into something worthy of being called 
HTTP. Doing research and development on Web security is a very different kind 
of work, and the two don't mix well, IME.



--
Mark Nottingham   http://www.mnot.net/



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Stephen Farrell]

On 02/25/2012 06:23 PM, Julian Reschke wrote:

On 2012-02-25 18:44, Stephen Farrell wrote:

...
I don't think fixing or changing the framework will give us better
auth schemes by itself. (Better auth schemes may or may not require
changes to the framework, I dunno.)

So I think you're raising a side issue here really.
...


Well, I'm one of the editors of the authentication framework spec, so if
there's something wrong with it, I'd like to know.

So if we collectively think that the framework probably is ok, and that
we *do* need a new authentication scheme, what's stopping us to start
that activity *right now*?


I believe I answered just that question from you earlier today.
So you must be looking for someone else's answer I guess. Or
perhaps I'm confused.

S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Julian Reschke]

On 2012-02-25 18:44, Stephen Farrell wrote:

...
I don't think fixing or changing the framework will give us better
auth schemes by itself. (Better auth schemes may or may not require
changes to the framework, I dunno.)

So I think you're raising a side issue here really.
...


Well, I'm one of the editors of the authentication framework spec, so if 
there's something wrong with it, I'd like to know.


So if we collectively think that the framework probably is ok, and that 
we *do* need a new authentication scheme, what's stopping us to start 
that activity *right now*?


Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Stephen Farrell]

On 02/25/2012 02:20 PM, Julian Reschke wrote:

On 2012-02-25 15:13, Stephen Farrell wrote:

On 02/25/2012 02:03 PM, Julian Reschke wrote:


If we just need a new authentication scheme, nothing stops people from
working on that right now.


I don't agree with you there - the perceived low probability that
something will be deployed is a real disincentive here. We have had
people wanting to do work on this and have been told there's no point
because it won't get adopted.


Just checking: so you think what's needed is a normative requirement to
implement the new scheme? Do you really believe that that's what holding
up improvements in this area?


The first thing is not something I said and I don't know quite what
it means so its also not something I believe. I therefore also do not
believe the 2nd thing.


> I don't see how that should affect HTTP/2.0.

Well, a number of people have noticed that current schemes
are getting long in the tooth and fixing stuff like that when
you do a major rev of a protocol is quite a reasonable thing
to do.


If there's something from with the framework, let's fix the framework.
That's already covered by the current charter, no?


I don't think fixing or changing the framework will give us better
auth schemes by itself. (Better auth schemes may or may not require
changes to the framework, I dunno.)

So I think you're raising a side issue here really.

S


If the "right" way to do security needs changes in the HTTP/1.1
authentication framework, then we should fix/augment/tune HTTP/1.1. It's
not going to go away anytime soon.


Sure, I agree with that and think the plan above allows for it.


My point being: this is something we already do in httpbis. What's
missing is concrete bug reports.

Best regards, Julian



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Julian Reschke]

On 2012-02-25 15:13, Stephen Farrell wrote:



On 02/25/2012 02:03 PM, Julian Reschke wrote:

On 2012-02-25 14:46, Stephen Farrell wrote:

...
Yeah that's a tricky one. While one might like to
see "one or more" in both places that might not be
practical.

In the proposal above the goal is that httpbis pick one
or more but recognising the reality that we might not get
a new proposal that httpbis will accept and that folks
will really implement and deploy.

So:
Goal = one or more
Reluctant recognition of reality = zero or more

With this plan if httpbis in fact select zero new proposals
that would represent a failure for all concerned. The "zero
or more" term is absolutely not intended to provide a way to
just punt on the question.

Such a failure at the point where httpbis was re-chartering
to work on a HTTP/2.0 selection with no better security than
we now have is probably better evaluated as a whole - I
guess the question for the IETF/IESG at that point would
be whether the Internet would be better with or without
such a beast, or better waiting a while until the security
thing did get fixed.

I can imagine an argument might ensue about that;-)
...


If we just need a new authentication scheme, nothing stops people from
working on that right now.


I don't agree with you there - the perceived low probability that
something will be deployed is a real disincentive here. We have had
people wanting to do work on this and have been told there's no point
because it won't get adopted.


Just checking: so you think what's needed is a normative requirement to 
implement the new scheme? Do you really believe that that's what holding 
up improvements in this area?



 > I don't see how that should affect HTTP/2.0.

Well, a number of people have noticed that current schemes
are getting long in the tooth and fixing stuff like that when
you do a major rev of a protocol is quite a reasonable thing
to do.


If there's something from with the framework, let's fix the framework. 
That's already covered by the current charter, no?



If the "right" way to do security needs changes in the HTTP/1.1
authentication framework, then we should fix/augment/tune HTTP/1.1. It's
not going to go away anytime soon.


Sure, I agree with that and think the plan above allows for it.


My point being: this is something we already do in httpbis. What's 
missing is concrete bug reports.


Best regards, Julian

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Stephen Farrell]

On 02/25/2012 02:03 PM, Julian Reschke wrote:

On 2012-02-25 14:46, Stephen Farrell wrote:

...
Yeah that's a tricky one. While one might like to
see "one or more" in both places that might not be
practical.

In the proposal above the goal is that httpbis pick one
or more but recognising the reality that we might not get
a new proposal that httpbis will accept and that folks
will really implement and deploy.

So:
Goal = one or more
Reluctant recognition of reality = zero or more

With this plan if httpbis in fact select zero new proposals
that would represent a failure for all concerned. The "zero
or more" term is absolutely not intended to provide a way to
just punt on the question.

Such a failure at the point where httpbis was re-chartering
to work on a HTTP/2.0 selection with no better security than
we now have is probably better evaluated as a whole - I
guess the question for the IETF/IESG at that point would
be whether the Internet would be better with or without
such a beast, or better waiting a while until the security
thing did get fixed.

I can imagine an argument might ensue about that;-)
...


If we just need a new authentication scheme, nothing stops people from
working on that right now.


I don't agree with you there - the perceived low probability that
something will be deployed is a real disincentive here. We have had
people wanting to do work on this and have been told there's no point
because it won't get adopted.

> I don't see how that should affect HTTP/2.0.

Well, a number of people have noticed that current schemes
are getting long in the tooth and fixing stuff like that when
you do a major rev of a protocol is quite a reasonable thing
to do.


If the "right" way to do security needs changes in the HTTP/1.1
authentication framework, then we should fix/augment/tune HTTP/1.1. It's
not going to go away anytime soon.


Sure, I agree with that and think the plan above allows for it.

S



Best regards, Julian


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Julian Reschke]

On 2012-02-25 14:46, Stephen Farrell wrote:

...
Yeah that's a tricky one. While one might like to
see "one or more" in both places that might not be
practical.

In the proposal above the goal is that httpbis pick one
or more but recognising the reality that we might not get
a new proposal that httpbis will accept and that folks
will really implement and deploy.

So:
Goal = one or more
Reluctant recognition of reality = zero or more

With this plan if httpbis in fact select zero new proposals
that would represent a failure for all concerned. The "zero
or more" term is absolutely not intended to provide a way to
just punt on the question.

Such a failure at the point where httpbis was re-chartering
to work on a HTTP/2.0 selection with no better security than
we now have is probably better evaluated as a whole - I
guess the question for the IETF/IESG at that point would
be whether the Internet would be better with or without
such a beast, or better waiting a while until the security
thing did get fixed.

I can imagine an argument might ensue about that;-)
...


If we just need a new authentication scheme, nothing stops people from 
working on that right now. I don't see how that should affect HTTP/2.0.


If the "right" way to do security needs changes in the HTTP/1.1 
authentication framework, then we should fix/augment/tune HTTP/1.1. It's 
not going to go away anytime soon.


Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Stephen Farrell]

Hiya,

On 02/25/2012 02:05 AM, Mark Nottingham wrote:

Hi Stephen,

On 24/02/2012, at 11:54 PM, Stephen Farrell wrote:



On 02/24/2012 01:24 AM, Roy T. Fielding wrote:

On Feb 23, 2012, at 5:18 PM, Tim Bray wrote:

On Thu, Feb 23, 2012 at 5:13 PM, Roy T. Fielding   wrote:


How many times do we have to do this before we declare insanity?
I don't care how much risk it adds to the HTTP charter.  They are
all just meaningless deadlines anyway.  If we want HTTP to have
something other than Basic (1993) and Digest (1995) authentication,
then it had better be part of *this* charter so that the proposals
can address them.


Well, Digest already isn't used by anyone :)


A popular misconception because it works unseen.  See tools.ietf.org


Seriously, someone needs to propose some charter language or this
discussion is a no-op.  -Tim


"Proposals for new HTTP authentication schemes are in scope."


How would a plan like the following look to folks:

- httpbis is chartered to include auth mechanism work as
  per the above (or whatever text goes into the charter)
- that'll generate a slew of proposals, some good, some
  bad, some better-than-current and some too complex
- plan is for httpbis to pick something (one or more if
  they want, but one better-than-current one is the goal)
- give all the above a short timeframe (this year, pick
  which to work on at the same time as re-chartering for
  the details of HTTP/2.0 maybe)
- httpbis pick what they want, (zero or more) and go
  do their stuff


Is the goal for HTTPbis "one or more" or "zero or more"? I see both above.

Again - I'm absolutely fine with soliciting proposals, but requiring output is 
a different thing.


Yeah that's a tricky one. While one might like to
see "one or more" in both places that might not be
practical.

In the proposal above the goal is that httpbis pick one
or more but recognising the reality that we might not get
a new proposal that httpbis will accept and that folks
will really implement and deploy.

So:
   Goal = one or more
   Reluctant recognition of reality = zero or more

With this plan if httpbis in fact select zero new proposals
that would represent a failure for all concerned. The "zero
or more" term is absolutely not intended to provide a way to
just punt on the question.

Such a failure at the point where httpbis was re-chartering
to work on a HTTP/2.0 selection with no better security than
we now have is probably better evaluated as a whole - I
guess the question for the IETF/IESG at that point would
be whether the Internet would be better with or without
such a beast, or better waiting a while until the security
thing did get fixed.

I can imagine an argument might ensue about that;-)

S


Thanks,


--
Mark Nottingham   http://www.mnot.net/





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Doug Barton]

On 02/24/2012 07:38, Andrew Sullivan wrote:
> On Fri, Feb 24, 2012 at 01:54:32PM +1100, Mark Andrews wrote:
>>
>> In message <4f46bfdf.3070...@dougbarton.us>, Doug Barton writes:
>>>
>>> 2782 was published 12 years ago this month. I suppose it can be
>>> considered mature enough to deploy at this point? :)
>>
>> +1000
> 
> Over in spfbis, people are arguing that the SPF RRTYPE should be
> deprecated and abandoned in SPF because nobody uses it because of
> practical difficulties in getting new RRTYPEs deployed.  What makes us
> think that the arguments in favour of SRV are going to find more
> fertile ground?

Because I emphasized the point that SRV has been around for 12 years? I
have enough experience to know how difficult it is to deploy new RRs.
SRV is not new.


Doug

-- 

It's always a long day; 86400 doesn't fit into a short.

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Mark Nottingham]

Hi Stephen,

On 24/02/2012, at 11:54 PM, Stephen Farrell wrote:

> 
> On 02/24/2012 01:24 AM, Roy T. Fielding wrote:
>> On Feb 23, 2012, at 5:18 PM, Tim Bray wrote:
>>> On Thu, Feb 23, 2012 at 5:13 PM, Roy T. Fielding  wrote:
>>> 
 How many times do we have to do this before we declare insanity?
 I don't care how much risk it adds to the HTTP charter.  They are
 all just meaningless deadlines anyway.  If we want HTTP to have
 something other than Basic (1993) and Digest (1995) authentication,
 then it had better be part of *this* charter so that the proposals
 can address them.
>>> 
>>> Well, Digest already isn't used by anyone :)
>> 
>> A popular misconception because it works unseen.  See tools.ietf.org
>> 
>>> Seriously, someone needs to propose some charter language or this
>>> discussion is a no-op.  -Tim
>> 
>> "Proposals for new HTTP authentication schemes are in scope."
> 
> How would a plan like the following look to folks:
> 
> - httpbis is chartered to include auth mechanism work as
>  per the above (or whatever text goes into the charter)
> - that'll generate a slew of proposals, some good, some
>  bad, some better-than-current and some too complex
> - plan is for httpbis to pick something (one or more if
>  they want, but one better-than-current one is the goal)
> - give all the above a short timeframe (this year, pick
>  which to work on at the same time as re-chartering for
>  the details of HTTP/2.0 maybe)
> - httpbis pick what they want, (zero or more) and go
>  do their stuff

Is the goal for HTTPbis "one or more" or "zero or more"? I see both above.

Again - I'm absolutely fine with soliciting proposals, but requiring output is 
a different thing.

Thanks,


--
Mark Nottingham   http://www.mnot.net/



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Yoav Nir]

On Feb 24, 2012, at 5:02 PM, Paul Hoffman wrote:

> On Feb 24, 2012, at 4:54 AM, Stephen Farrell wrote:
> 
>>> "Proposals for new HTTP authentication schemes are in scope."
>> 
>> How would a plan like the following look to folks:
>> 
>> - httpbis is chartered to include auth mechanism work as
>> per the above (or whatever text goes into the charter)



>> 
>> Might that be a way forward that'll give enough folks
>> enough of what they want/need?
> 
> 
> It would, but I would like to give a counter-proposal that I think will use 
> people's different talents better:
> 
> - new wg on developing http authentication mechanisms is chartered soon (BoF 
> in Paris); call it the ham wg
> - httpbis is chartered to follow the work of the ham wg and is required to 
> make sure that the authentication framework in http 2.0 works for as many of 
> the proposals from the ham wg as possible
> - ham wg is responsible for most of what you list above
> - http2.0 document says "the mandatory to implement auth mechanisms are named 
> in that RFC over there", which comes from the ham wg
> 
> There will be overlap in wg membership, but not nearly as much as would be 
> needed for your proposal.

I like the idea, but there is always the danger of the HAM working group either 
getting stuck with multiple non-interoperable proposals like we've seen at 
IPsecME with the PAKE work.

There is also the possibility of getting stuck with conflicting requirements. 
For example, there will be a need to use existing user databases 
(RADIUS/DIAMETER servers, LDAP directories), but that is hard to reconcile with 
the preference for ZKPs.

I'm not really worried, because HTTP/2.0 is bound to take a long time, and 
there will be plenty of opportunity for chair and ADs to step in and intervene 
if the wg actually does that.

On a more technical note, we are 12 days past the cutoff date for new BoF 
session requests, so it's probably too late for a BoF in Paris. 

Yoav

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[John C Klensin]

--On Friday, February 24, 2012 16:58 +0100 Patrik Fältström
 wrote:

> On 24 feb 2012, at 16:38, Andrew Sullivan wrote:
> 
>> Over in spfbis, people are arguing that the SPF RRTYPE should
>> be deprecated and abandoned in SPF because nobody uses it
>> because of practical difficulties in getting new RRTYPEs
>> deployed.  What makes us think that the arguments in favour
>> of SRV are going to find more fertile ground?
> 
> Because people disagree on whether it is actually hard to get
> new RRTYPEs deployed.
> 
> I for example do completely disagree on it being hard. Sure,
> your user interface in the gui of your favorite $EDITOR might
> not support the new RRTYPE, but should that constrain
> deployment of good standards?

Patrik,

While I don't see it as hard as Andrew does, I don't see it as
easy either.  The problem isn't one's favorite $EDITOR.  It is
the number of folks who, for lots of reasons, haven't upgraded
from operating systems, resolvers, etc., that don't support
newer RRTYPES.   Remember that, while Windows 7 is getting some
of the market share that Vista never did, there are still a huge
number of XP systems out there -- many of them in the hands of
people and organizations who aren't going to make the hardware
investment to upgrade in a difficult economy.  The situation
with the Mac platform actually isn't much better -- I know a lot
of people who haven't (and can't) upgrade from OS 9, much less
to the latest carnivorous feline.  

SRV has the advantage of many year's head start and more utility
to more protocols over, e.g., SPF but the reality remains that,
if some users have support for an important new RRTYPE and
others don't, we have either an inconsistent user experience
(more confusion, more support calls, etc.) or, as we have seen
with DNAME, a need to carry around complex workarounds that can
lead to bugs, vunerabilities, or, ahem, inconsistent user
experience.

And, fwiw, I'm actually much more concerned about use of the DNS
for any part of the process if we don't have broad consensus in
and between the IETF and the implementer community about whether
IRIs or URIs are authoritative and about how domain names
containing IDN labels are encoded in either.   I'm equally
concerned if some organization of our mutual acquaintance is
determined to declare the existence of equivalent names in the
DNS that will create user expectations that certs and comparison
mechanisms cannot support.

--On Thursday, February 23, 2012 14:38 -0800 Doug Barton
 wrote:

> 2782 was published 12 years ago this month. I suppose it can be
> considered mature enough to deploy at this point? :)

One might wish.  But real maturity has to be based on
implementation and deployment, not just publication dates.   I
note, for example, that RFC 736 (an old favorite example of mine
for several reasons) was published over 34 years ago is, like
2782, still at Proposed Standard, and, sadly, hasn't gone
anywhere (at least in the last decade or so).   Certainly it is
elderly as Internet protocols go, but I don't think the leap
from "elderly" to "mature" is obviously justified.

john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Willy Tarreau]

On Thu, Feb 23, 2012 at 05:23:45PM -0800, Paul Hoffman wrote:
> If only it were that simple. If the answer is "design an HTTP auth mechanism
> that is better than Digest", then this is a tractable goal. If it is "get
> IETF consensus on that auth mechanism", then it isn't. The latter has proven
> to be impossible because people say (possibly rightly) that web developers
> don't want auth mechanisms that use the browser chrome: they want auth in
> HTML, and anything that relies on the browser chrome is insufficient.

Maybe but you still need HTTP-based auth for proxies anyway. Also, I
partially disagree with your point, seeing the number of applications
in enterprise which rely on the hated NTLM auth which is also HTTP-based ;
they're using it because it's transparent to the user, and enterprise
customers do ask for such transparent auth schemes.

There would also be much less need for cookies if auth was carried by the
browser, and this would let the user log off. So I think there's a need
for this.

Regards,
Willy

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Patrik Fältström]

On 24 feb 2012, at 16:38, Andrew Sullivan wrote:

> Over in spfbis, people are arguing that the SPF RRTYPE should be
> deprecated and abandoned in SPF because nobody uses it because of
> practical difficulties in getting new RRTYPEs deployed.  What makes us
> think that the arguments in favour of SRV are going to find more
> fertile ground?

Because people disagree on whether it is actually hard to get new RRTYPEs 
deployed.

I for example do completely disagree on it being hard. Sure, your user 
interface in the gui of your favorite $EDITOR might not support the new RRTYPE, 
but should that constrain deployment of good standards?

   Patrik

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Andrew Sullivan]

On Fri, Feb 24, 2012 at 01:54:32PM +1100, Mark Andrews wrote:
> 
> In message <4f46bfdf.3070...@dougbarton.us>, Doug Barton writes:
> > 
> > 2782 was published 12 years ago this month. I suppose it can be
> > considered mature enough to deploy at this point? :)
> 
> +1000

Over in spfbis, people are arguing that the SPF RRTYPE should be
deprecated and abandoned in SPF because nobody uses it because of
practical difficulties in getting new RRTYPEs deployed.  What makes us
think that the arguments in favour of SRV are going to find more
fertile ground?

Best,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Paul Hoffman]

On Feb 24, 2012, at 4:54 AM, Stephen Farrell wrote:

>> "Proposals for new HTTP authentication schemes are in scope."
> 
> How would a plan like the following look to folks:
> 
> - httpbis is chartered to include auth mechanism work as
>  per the above (or whatever text goes into the charter)

> - that'll generate a slew of proposals, some good, some
>  bad, some better-than-current and some too complex
> - plan is for httpbis to pick something (one or more if
>  they want, but one better-than-current one is the goal)
> - give all the above a short timeframe (this year, pick
>  which to work on at the same time as re-chartering for
>  the details of HTTP/2.0 maybe)
> - httpbis pick what they want, (zero or more) and go
>  do their stuff
> 
> - if there's still enough interest in some proposals
>  that were not picked by httpbis we then try charter a sec
>  area wg to develop experimental specs for those so
>  they're off the critical path for httpbis (the rest die
>  unloved;-)
> - those experimental specs would be REQUIRED to work with
>  http/1.1 and/or http/2.0 (as appropriate) with no change
>  required to http; that'd be in the charter for that
>  putative sec wg
> - that sec wg charter might also say that the putative
>  wg is not allowed to add new schemes until the
>  originally chartered ones are completed (to avoid
>  people turning up every week with their shiny new
>  scheme)
> 
> Might that be a way forward that'll give enough folks
> enough of what they want/need?


It would, but I would like to give a counter-proposal that I think will use 
people's different talents better:

- new wg on developing http authentication mechanisms is chartered soon (BoF in 
Paris); call it the ham wg
- httpbis is chartered to follow the work of the ham wg and is required to make 
sure that the authentication framework in http 2.0 works for as many of the 
proposals from the ham wg as possible
- ham wg is responsible for most of what you list above
- http2.0 document says "the mandatory to implement auth mechanisms are named 
in that RFC over there", which comes from the ham wg

There will be overlap in wg membership, but not nearly as much as would be 
needed for your proposal.

--Paul Hoffman

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Stephen Farrell]

On 02/24/2012 01:24 AM, Roy T. Fielding wrote:

On Feb 23, 2012, at 5:18 PM, Tim Bray wrote:

On Thu, Feb 23, 2012 at 5:13 PM, Roy T. Fielding  wrote:


How many times do we have to do this before we declare insanity?
I don't care how much risk it adds to the HTTP charter.  They are
all just meaningless deadlines anyway.  If we want HTTP to have
something other than Basic (1993) and Digest (1995) authentication,
then it had better be part of *this* charter so that the proposals
can address them.


Well, Digest already isn't used by anyone :)


A popular misconception because it works unseen.  See tools.ietf.org


Seriously, someone needs to propose some charter language or this
discussion is a no-op.  -Tim


"Proposals for new HTTP authentication schemes are in scope."


How would a plan like the following look to folks:

- httpbis is chartered to include auth mechanism work as
  per the above (or whatever text goes into the charter)
- that'll generate a slew of proposals, some good, some
  bad, some better-than-current and some too complex
- plan is for httpbis to pick something (one or more if
  they want, but one better-than-current one is the goal)
- give all the above a short timeframe (this year, pick
  which to work on at the same time as re-chartering for
  the details of HTTP/2.0 maybe)
- httpbis pick what they want, (zero or more) and go
  do their stuff

- if there's still enough interest in some proposals
  that were not picked by httpbis we then try charter a sec
  area wg to develop experimental specs for those so
  they're off the critical path for httpbis (the rest die
  unloved;-)
- those experimental specs would be REQUIRED to work with
  http/1.1 and/or http/2.0 (as appropriate) with no change
  required to http; that'd be in the charter for that
  putative sec wg
- that sec wg charter might also say that the putative
  wg is not allowed to add new schemes until the
  originally chartered ones are completed (to avoid
  people turning up every week with their shiny new
  scheme)

Might that be a way forward that'll give enough folks
enough of what they want/need?

Cheers,
S.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Patrik Fältström]

On 24 feb 2012, at 03:54, Mark Andrews wrote:

> In message <4f46bfdf.3070...@dougbarton.us>, Doug Barton writes:
>> For my money it would be quite important for an HTTP 2.0 definition to
>> make SRV DNS records a full-fledged participant in the standard. Minimum
>> once a month there is someone asking for help on bind-users@ for which
>> the answer is, "The solution to that _would_ be SRV records, if they
>> were supported."
>> 
>> 2782 was published 12 years ago this month. I suppose it can be
>> considered mature enough to deploy at this point? :)
> 
> +1000

Indeed. Including how to handle the comparison of domain name in the URL / 
domain name in the target in the SRV with the domain name in a cert. I.e. 
relationship with DANE.

   Patrik

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Mark Andrews]

In message <4f46bfdf.3070...@dougbarton.us>, Doug Barton writes:
> For my money it would be quite important for an HTTP 2.0 definition to
> make SRV DNS records a full-fledged participant in the standard. Minimum
> once a month there is someone asking for help on bind-users@ for which
> the answer is, "The solution to that _would_ be SRV records, if they
> were supported."
> 
> 2782 was published 12 years ago this month. I suppose it can be
> considered mature enough to deploy at this point? :)

+1000

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Mark Nottingham]

On 24/02/2012, at 12:24 PM, Roy T. Fielding wrote:

> On Feb 23, 2012, at 5:18 PM, Tim Bray wrote:
>> On Thu, Feb 23, 2012 at 5:13 PM, Roy T. Fielding  wrote:
>> 
>>> How many times do we have to do this before we declare insanity?
>>> I don't care how much risk it adds to the HTTP charter.  They are
>>> all just meaningless deadlines anyway.  If we want HTTP to have
>>> something other than Basic (1993) and Digest (1995) authentication,
>>> then it had better be part of *this* charter so that the proposals
>>> can address them.
>> 
>> Well, Digest already isn't used by anyone :)
> 
> A popular misconception because it works unseen.  See tools.ietf.org
> 
>> Seriously, someone needs to propose some charter language or this
>> discussion is a no-op.  -Tim
> 
> "Proposals for new HTTP authentication schemes are in scope."

No one has said they're out of scope; this discussion has been about whether -- 
at this point in time, before we have proposals -- we require the outcome to 
jump through some particular hoop regarding security. 


Cheers,



--
Mark Nottingham   http://www.mnot.net/



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Roy T. Fielding]

On Feb 23, 2012, at 5:23 PM, Paul Hoffman wrote:
> On Feb 23, 2012, at 5:13 PM, Roy T. Fielding wrote:
> 
>> I don't care how much risk it adds to the HTTP charter.  They are
>> all just meaningless deadlines anyway.  If we want HTTP to have
>> something other than Basic (1993) and Digest (1995) authentication,
>> then it had better be part of *this* charter so that the proposals
>> can address them.
> 
> 
> If only it were that simple. If the answer is "design an HTTP auth mechanism 
> that is better than Digest", then this is a tractable goal. If it is "get 
> IETF consensus on that auth mechanism", then it isn't. The latter has proven 
> to be impossible because people say (possibly rightly) that web developers 
> don't want auth mechanisms that use the browser chrome: they want auth in 
> HTML, and anything that relies on the browser chrome is insufficient.

I don't need IETF consensus, just rough consensus and running code,
and I have no need to satisfy folks who think the Web is a browser.
The hard part is deploying anything that is incompatible with
already-deployed clients without letting them fall back to basic.

It is a trivial problem compared to choosing a new, non-MIME syntax.

What "web developers" want is based on what they can do today,
not what they can expect from an entirely new protocol.

> Notice how the topic changed from "HTTP" to "web" for the security discussion 
> but not for the httpbis charter discussion? That topic-change has derailed 
> the HTTP authentication discussions at recent (and not-so-recent) IETF 
> meetings.


It didn't derail them.  They were not on any rails to begin with.

The problem with defining security in a separate group without
shipping implementations is that there is no need to compromise,
no need to identify and resolve specific use cases, and no need
to do something better than nothing.

If we add a requirement to HTTP/2.0 that user authentication MUST
be accomplished via a mechanism not subject to UI spoofing,
then that's what people will implement (if they implement at all).
The protocol can give the server all the control it wants over the
display of a background or separate window explaining what to do
in that other mechanism-not-subject-to-spoofing.  Give people just
enough rope to solve that problem without hanging themselves, and
the rest of HTTP (non-browser clients) can implement right now.

> If the charter has "develop HTTP authentication mechanisms beyond Digest", 
> that's great: we already have seen about five proposals in the past few years 
> for those, some of them with security analyses. If the charter says "...and 
> specify one that is mandatory to implement", that seems prone to consensus 
> failure because of religion about zero-knowledge proofs versus operational 
> simplicity, but I would be overjoyed to be wrong about that.

I'd be happy with several imperfect mechanisms with differing
trade-offs that can be implemented in parallel.

Roy

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Tim Bray]

On Thu, Feb 23, 2012 at 5:24 PM, Roy T. Fielding  wrote:

>> Seriously, someone needs to propose some charter language or this
>> discussion is a no-op.  -Tim
>
> "Proposals for new HTTP authentication schemes are in scope."

+1

I don’t think we’ll get one, but in the unlikely event someone can
build consensus for something, there’s no reason to brand it as
out-of-bounds.  -T
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Roy T. Fielding]

On Feb 23, 2012, at 5:18 PM, Tim Bray wrote:
> On Thu, Feb 23, 2012 at 5:13 PM, Roy T. Fielding  wrote:
> 
>> How many times do we have to do this before we declare insanity?
>> I don't care how much risk it adds to the HTTP charter.  They are
>> all just meaningless deadlines anyway.  If we want HTTP to have
>> something other than Basic (1993) and Digest (1995) authentication,
>> then it had better be part of *this* charter so that the proposals
>> can address them.
> 
> Well, Digest already isn't used by anyone :)

A popular misconception because it works unseen.  See tools.ietf.org

> Seriously, someone needs to propose some charter language or this
> discussion is a no-op.  -Tim

"Proposals for new HTTP authentication schemes are in scope."

Roy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Paul Hoffman]

On Feb 23, 2012, at 5:13 PM, Roy T. Fielding wrote:

> I don't care how much risk it adds to the HTTP charter.  They are
> all just meaningless deadlines anyway.  If we want HTTP to have
> something other than Basic (1993) and Digest (1995) authentication,
> then it had better be part of *this* charter so that the proposals
> can address them.


If only it were that simple. If the answer is "design an HTTP auth mechanism 
that is better than Digest", then this is a tractable goal. If it is "get IETF 
consensus on that auth mechanism", then it isn't. The latter has proven to be 
impossible because people say (possibly rightly) that web developers don't want 
auth mechanisms that use the browser chrome: they want auth in HTML, and 
anything that relies on the browser chrome is insufficient.

Notice how the topic changed from "HTTP" to "web" for the security discussion 
but not for the httpbis charter discussion? That topic-change has derailed the 
HTTP authentication discussions at recent (and not-so-recent) IETF meetings.

If the charter has "develop HTTP authentication mechanisms beyond Digest", 
that's great: we already have seen about five proposals in the past few years 
for those, some of them with security analyses. If the charter says "...and 
specify one that is mandatory to implement", that seems prone to consensus 
failure because of religion about zero-knowledge proofs versus operational 
simplicity, but I would be overjoyed to be wrong about that.

--Paul Hoffman

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Tim Bray]

On Thu, Feb 23, 2012 at 5:13 PM, Roy T. Fielding  wrote:

> How many times do we have to do this before we declare insanity?
> I don't care how much risk it adds to the HTTP charter.  They are
> all just meaningless deadlines anyway.  If we want HTTP to have
> something other than Basic (1993) and Digest (1995) authentication,
> then it had better be part of *this* charter so that the proposals
> can address them.

Well, Digest already isn't used by anyone :)

Seriously, someone needs to propose some charter language or this
discussion is a no-op.  -Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Roy T. Fielding]

On Feb 22, 2012, at 9:39 AM, Peter Saint-Andre wrote:

> On 2/22/12 10:31 AM, Paul Hoffman wrote:
>> The earnest calls for better authentication on this thread appear to
>> ignore the fact that the very things that are being requested were
>> put out of scope for the websec WG in their charter. I hope that no
>> one things that a WG in the Applications Area will be better equipped
>> to come up with a better authentication mechanism than one in the
>> Security Area.
> 
> The WebSec WG is in the Applications Area.
> 
>> Asking the HTTPheads to guess what the securityheads might want is
>> not a good way to design HTTP 2.0.
> 
> Probably not.
> 
>> Proposal: leave the httpbis WG charter as-is and re-charter the
>> websec WG to consider what is needed in the HTTP authentication
>> model. Later, recharter the websec WG to, you know, actually do the
>> security work for authentication.
> 
> Or charter a separate WG to focus on HTTP authentication. (You might
> recall that the BoF leading to formation of the WebSec WG was entitled
> HASMAT = "HTTP Application Security Minus Authentication and Transport"
> or somesuch.)

Please understand that this exact same discussion was had in 1994 and
the IESG decided that the applications area couldn't possibly do this
work on their own, so they created a security area working group to
handle it.  That HTTP Security group, which was dominated by folks who
did not have any implementations of HTTP, decided to ignore the problem
for which they were chartered and instead invented SHTTP.

More importantly, the effect of that decision was that the people who
get work done at the IETF were prevented from improving HTTP's auth
mechanisms because it was out of scope, while the people who had it
in scope had no corresponding incentive to get it DONE.

Every time this topic comes up, people want to shove it off to some
other working group that is somehow going to magically get off its
collective ass and do real work.  Why?  It doesn't work.  It never
has worked.  We've gone through four iterations now of revising HTTP,
each one starting off with the same discussion, and each one concluding
that auth would be better owned by someone else.

There is nobody else.

How many times do we have to do this before we declare insanity?
I don't care how much risk it adds to the HTTP charter.  They are
all just meaningless deadlines anyway.  If we want HTTP to have
something other than Basic (1993) and Digest (1995) authentication,
then it had better be part of *this* charter so that the proposals
can address them.

Roy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Julian Reschke]

On 2012-02-23 23:33, Doug Barton wrote:

I don't *quite* go back 2 decades, but a big +1 to "all my experiences
with bolt-on security have been bad."


bolt-on != modular/optional

If you want to "require" security in whatever comes out of this 
activity, you better define what security means, and also explain what 
keeps you from doing it right now.


Again: is there anything in the HTTP/1.1 authentication *framework* that 
prevents a "good" authentication scheme to be defined? I really like to 
know.


Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Doug Barton]

For my money it would be quite important for an HTTP 2.0 definition to
make SRV DNS records a full-fledged participant in the standard. Minimum
once a month there is someone asking for help on bind-users@ for which
the answer is, "The solution to that _would_ be SRV records, if they
were supported."

2782 was published 12 years ago this month. I suppose it can be
considered mature enough to deploy at this point? :)


Doug

-- 

It's always a long day; 86400 doesn't fit into a short.

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Tim Bray]

Your points granted, the feeling of the HTTP-using community is, by
and large, that HTTP security/authz as it stands is “good enough”.
Are you arguing that the security of HTTP 2.0 should be required to be
qualitatively better?  If so, someone is going to need to provide some
useful language to put in the draft charter so that we can argue about
specifics not armwaving.
-Tim

On Thu, Feb 23, 2012 at 10:00 AM, Leif Sawyer  wrote:
> I've got the last 2 decades of experience trying to deal with security on the 
> network.
>
> 95% is dealing with the peculiarities of the "bolt-on"  after-thoughts.
>
> I would much prefer seeing security  designed-in, with the flexibility to 
> deal with
> the future...
>
> 
> From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of RJ Atkinson 
> [rja.li...@gmail.com]
> Sent: Thursday, February 23, 2012 8:59 AM
> To: ietf@ietf.org
> Subject: Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
>
> On 23  Feb 2012, at 11:13 , Julian Reschke wrote:
>> On 2012-02-22 18:01, RJ Atkinson wrote:
>>> Security that works well and is practical to implement
>>> needs to be designed-in, not bolted-on later.
>>
>> I would say: security needs to be orthogonal.
>
> There are at least 2 decades of experience that
> security has to be design-in, rather than bolted-on,
> for it to work well -- and for it to be practical
> to implement.
>
> I hear that you don't agree, but the IETF experience
> on this specific point really is quite clear.  Add-on
> security doesn't work.
>
> Yours,
>
> Ran
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Doug Barton]

I don't *quite* go back 2 decades, but a big +1 to "all my experiences
with bolt-on security have been bad."


Doug


On 02/23/2012 10:00, Leif Sawyer wrote:
> I've got the last 2 decades of experience trying to deal with security on the 
> network.
> 
> 95% is dealing with the peculiarities of the "bolt-on"  after-thoughts.
> 
> I would much prefer seeing security  designed-in, with the flexibility to 
> deal with
> the future...
> 
> 
> From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of RJ Atkinson 
> [rja.li...@gmail.com]
> Sent: Thursday, February 23, 2012 8:59 AM
> To: ietf@ietf.org
> Subject: Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
> 
> On 23  Feb 2012, at 11:13 , Julian Reschke wrote:
>> On 2012-02-22 18:01, RJ Atkinson wrote:
>>> Security that works well and is practical to implement
>>> needs to be designed-in, not bolted-on later.
>>
>> I would say: security needs to be orthogonal.
> 
> There are at least 2 decades of experience that
> security has to be design-in, rather than bolted-on,
> for it to work well -- and for it to be practical
> to implement.
> 
> I hear that you don't agree, but the IETF experience
> on this specific point really is quite clear.  Add-on
> security doesn't work.
> 
> Yours,
> 
> Ran



-- 

It's always a long day; 86400 doesn't fit into a short.

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Leif Sawyer]

I've got the last 2 decades of experience trying to deal with security on the 
network.

95% is dealing with the peculiarities of the "bolt-on"  after-thoughts.

I would much prefer seeing security  designed-in, with the flexibility to deal 
with
the future...


From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of RJ Atkinson 
[rja.li...@gmail.com]
Sent: Thursday, February 23, 2012 8:59 AM
To: ietf@ietf.org
Subject: Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

On 23  Feb 2012, at 11:13 , Julian Reschke wrote:
> On 2012-02-22 18:01, RJ Atkinson wrote:
>> Security that works well and is practical to implement
>> needs to be designed-in, not bolted-on later.
>
> I would say: security needs to be orthogonal.

There are at least 2 decades of experience that
security has to be design-in, rather than bolted-on,
for it to work well -- and for it to be practical
to implement.

I hear that you don't agree, but the IETF experience
on this specific point really is quite clear.  Add-on
security doesn't work.

Yours,

Ran

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[RJ Atkinson]

On 23  Feb 2012, at 11:13 , Julian Reschke wrote:
> On 2012-02-22 18:01, RJ Atkinson wrote:
>> Security that works well and is practical to implement
>> needs to be designed-in, not bolted-on later.
> 
> I would say: security needs to be orthogonal.

There are at least 2 decades of experience that
security has to be design-in, rather than bolted-on,
for it to work well -- and for it to be practical
to implement.

I hear that you don't agree, but the IETF experience
on this specific point really is quite clear.  Add-on 
security doesn't work.

Yours,

Ran

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[David Harrington]

Point taken.

--
David Harrington
Director, Transport Area
Internet Engineering Task Force (IETF)
ietf...@comcast.net
+1-603-828-1401





On 2/22/12 12:31 PM, "Paul Hoffman"  wrote:

>The earnest calls for better authentication on this thread appear to
>ignore the fact that the very things that are being requested were put
>out of scope for the websec WG in their charter. I hope that no one
>things that a WG in the Applications Area will be better equipped to come
>up with a better authentication mechanism than one in the Security Area.
>
>Asking the HTTPheads to guess what the securityheads might want is not a
>good way to design HTTP 2.0.
>
>Proposal: leave the httpbis WG charter as-is and re-charter the websec WG
>to consider what is needed in the HTTP authentication model. Later,
>recharter the websec WG to, you know, actually do the security work for
>authentication.
>
>--Paul Hoffman


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Julian Reschke]

On 2012-02-22 18:01, RJ Atkinson wrote:

Earlier, Barry Leiba wrote, in part:

What we're looking at here is the need for an HTTP authentication
system that (for example) doesn't send reusable credentials,
is less susceptible to spoofing attacks, and so on.


+1

More generally, I support the concerns raised by Stephen Farrell,
Wes Hardaker, and others that if *any* work is to be done on HTTP,
then improving the authentication/confidentiality properties
ought to be a mandatory part of that work.


I'm still waiting for somebody to explain why this can't already be 
defined as HTTP/1.1 authentication mechanism.



The IETF has LOTS of experience that if strong(er) security
mechanisms are not *required* in a WG Charter *very explicitly*,
then that work will not happen at all.


Whether work happens nor not IMHO depends on getting the right people.


Security that works well and is practical to implement
needs to be designed-in, not bolted-on later.


I would say: security needs to be orthogonal.


Separately, I would also like to see the known-weak cryptographic
algorithms/modes (i.e. published literature indicates that
an algorithm, a mode, or both is weak) that are included with HTTP
(as separate from being part of TLS) formally get deprecated as part
of any HTTPbis work.   For example, the WG ought to consider
deprecating the use of the MD5, UNIXsum, and UNIXcksum algorithms
within HTTP Digests [RFC-2617] [RFC-3230].


So far HTTPbis was not chartered to revise any existing auth scheme 
(just the framework).


Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Salvatore Loreto]

On 2/22/12 12:40 AM, Mark Nottingham wrote:

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.

I agree with Mark on this point

/Salvatore


Regards,


--
Mark Nottingham
http://www.mnot.net/



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Peter Saint-Andre]

On 2/22/12 11:39 AM, Paul Hoffman wrote:
> On Feb 22, 2012, at 10:35 AM, Stephen Farrell wrote:
> 
>> Regardless of that you do have a fair point that asking apps folks
>> to do stuff that'll please security folks might be asking for
>> trouble:-)
>> 
>> However, the counter to that is that security folks doing stuff
>> without enough apps input might produce something that won't get
>> adopted which also doesn't produce the right end result.
>> 
>> Anyway, I think this topic, if tackled, won't lack interested
>> participants and will get plenty of security and apps input no
>> matter how we organise it.
> 
> 
> Peter St.Andre's suggestion of a separate WG to deal specifically
> with HTTP authentication seems like the best way to be sure both sets
> of parties are fully involved. If the IESG charters it within the
> next few months, the HTTP 2.0 work can be informed by any changes (if
> any) that are needed.

By the way, I forwarded this message to the http-a...@ietf.org list
(yes, we already have a discussion list for these topics). The small
sample of replies indicates that (1) folks would prefer to broaden the
topic to web authentication, not strictly HTTP authentication and (2)
not everyone who is interested in these topics subscribes to the more
general ietf-http...@w3.org list.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Paul Hoffman]

On Feb 22, 2012, at 10:35 AM, Stephen Farrell wrote:

> Regardless of that you do have a fair point that asking
> apps folks to do stuff that'll please security folks might
> be asking for trouble:-)
> 
> However, the counter to that is that security folks doing
> stuff without enough apps input might produce something that
> won't get adopted which also doesn't produce the right end
> result.
> 
> Anyway, I think this topic, if tackled, won't lack
> interested participants and will get plenty of security
> and apps input no matter how we organise it.


Peter St.Andre's suggestion of a separate WG to deal specifically with HTTP 
authentication seems like the best way to be sure both sets of parties are 
fully involved. If the IESG charters it within the next few months, the HTTP 
2.0 work can be informed by any changes (if any) that are needed.

--Paul Hoffman

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Stephen Farrell]

On 02/22/2012 05:52 PM, Paul Hoffman wrote:

On Feb 22, 2012, at 9:39 AM, Peter Saint-Andre wrote:


The WebSec WG is in the Applications Area.


Yeeps! My apologies. I guess seeing a room full of security regulars made me 
forget.



Regardless of that you do have a fair point that asking
apps folks to do stuff that'll please security folks might
be asking for trouble:-)

However, the counter to that is that security folks doing
stuff without enough apps input might produce something that
won't get adopted which also doesn't produce the right end
result.

Anyway, I think this topic, if tackled, won't lack
interested participants and will get plenty of security
and apps input no matter how we organise it.

S.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Paul Hoffman]

On Feb 22, 2012, at 9:39 AM, Peter Saint-Andre wrote:

> The WebSec WG is in the Applications Area.

Yeeps! My apologies. I guess seeing a room full of security regulars made me 
forget.

--Paul Hoffman

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Peter Saint-Andre]

On 2/22/12 10:31 AM, Paul Hoffman wrote:
> The earnest calls for better authentication on this thread appear to
> ignore the fact that the very things that are being requested were
> put out of scope for the websec WG in their charter. I hope that no
> one things that a WG in the Applications Area will be better equipped
> to come up with a better authentication mechanism than one in the
> Security Area.

The WebSec WG is in the Applications Area.

> Asking the HTTPheads to guess what the securityheads might want is
> not a good way to design HTTP 2.0.

Probably not.

> Proposal: leave the httpbis WG charter as-is and re-charter the
> websec WG to consider what is needed in the HTTP authentication
> model. Later, recharter the websec WG to, you know, actually do the
> security work for authentication.

Or charter a separate WG to focus on HTTP authentication. (You might
recall that the BoF leading to formation of the WebSec WG was entitled
HASMAT = "HTTP Application Security Minus Authentication and Transport"
or somesuch.)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Paul Hoffman]

The earnest calls for better authentication on this thread appear to ignore the 
fact that the very things that are being requested were put out of scope for 
the websec WG in their charter. I hope that no one things that a WG in the 
Applications Area will be better equipped to come up with a better 
authentication mechanism than one in the Security Area.

Asking the HTTPheads to guess what the securityheads might want is not a good 
way to design HTTP 2.0.

Proposal: leave the httpbis WG charter as-is and re-charter the websec WG to 
consider what is needed in the HTTP authentication model. Later, recharter the 
websec WG to, you know, actually do the security work for authentication.

--Paul Hoffman
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[RJ Atkinson]

Earlier, Barry Leiba wrote, in part:
> What we're looking at here is the need for an HTTP authentication
> system that (for example) doesn't send reusable credentials,
> is less susceptible to spoofing attacks, and so on.

+1

More generally, I support the concerns raised by Stephen Farrell, 
Wes Hardaker, and others that if *any* work is to be done on HTTP, 
then improving the authentication/confidentiality properties 
ought to be a mandatory part of that work.

The IETF has LOTS of experience that if strong(er) security
mechanisms are not *required* in a WG Charter *very explicitly*,
then that work will not happen at all.

Security that works well and is practical to implement 
needs to be designed-in, not bolted-on later.

Separately, I would also like to see the known-weak cryptographic
algorithms/modes (i.e. published literature indicates that
an algorithm, a mode, or both is weak) that are included with HTTP
(as separate from being part of TLS) formally get deprecated as part 
of any HTTPbis work.   For example, the WG ought to consider
deprecating the use of the MD5, UNIXsum, and UNIXcksum algorithms
within HTTP Digests [RFC-2617] [RFC-3230].

Yours,

Ran



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Albert Lunde]

It seems like what would be useful would be a way of bringing in trusted 
third-parties into authentication that didn't look like a 
man-in-the-middle attack, and didn't rely on JavaScript.


SAML "federation" (e.g. Shibboleth) is layered on top of HTML+HTTP,
but it, and most of the other existing WebSSO systems, rely on 
JavaScript tricks somewhere in their process.


Trusted third parties are presently more the domain of certificates or 
Kerberos, than HTTP as such.


SASL is another framework for layering authentication onto protocols, 
that's been worked on considerably. But I don't know if it can meet the 
needs of the browser-based market now being served by 
forms+cookies+JavaScript.


Finding a single authentication/authorization framework that serves the 
needs of both browser and non-broswer clients is hard.


Scott Cantor has written a lot about why global logout for Shibboleth is 
hard to implement. Part of that may rest on the underlying legacy 
mechanisms they are using, but it's also a communication problem.


Having a local logout that really meant "stop sending cookies and 
credentials for realm X to these servers" and/or authentication realms 
that spanned servers might help, I don't know.


--
Albert Lunde  albert-lu...@northwestern.edu
  atlu...@panix.com  (address for personal mail)
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[David Harrington]

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)
ietf...@comcast.net
+1-603-828-1401





On 2/21/12 6:01 PM, "Stephen Farrell"  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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Hector Santos]

Barry Leiba wrote:

browser id, openid, and oauth are all authentication frameworks built
on top of HTTP



OAuth is an authorization framework, not an authentication one.  Please be
careful to make the distinction.

What we're looking at here is the need for an HTTP authentication system
that (for example) doesn't send reusable credentials, is less susceptible
to spoofing attacks, and so on.


Hi Barry, maybe I should review the drafts (or not), but if its hasn't 
been considered, this sounds like the only way possible is with a 
persistent IP connection session management concept.


I can relate it based on our PCI framework for the web server and much 
of the modeling was based on our existing non-http multi-device 
hosting servers already 100% based on a persistent connection IP or 
line, channel.  Definitely works in areas where only one browser or 
machine is allowed.


I was looking forwarding to further exploring WebSockets to possible 
be part of (revitaling) this solution as well, since it work nicely 
with the persistent IP concept with the backend.


On a related note, some web sites do this and I first saw it with 
facebook where it knows where I am logging in from. In a recent philly 
trip, I tried to log on and interestingly got a new login form where 
it indicated I was at a different location. I had to verify who I was 
again, if I recall via my email/login account at gmail.com.


--
Sincerely

Hector Santos
http://www.santronics.com
jabber: hec...@jabber.isdg.net


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Adrien de Croy]

Hi Julian,

On 02/21/2012 06:50 PM, Julian Reschke wrote:

On 2012-02-21 19:37, Stephen Farrell wrote:

...

I believe this should be orthogonal to HTTP/2.0. Is there a specific
thing that makes it impossible to use the existing authentication
framework?


Who knows? We don't have a protocol on the table yet. I
would imagine that some level of backwards compatibility
would be a requirement of course, or at least an issue to
be considered.

But the existing HTTP client authentication is also not
necessarily very useful, and there have been a number of
efforts to improve on that, none of which seem to have
gotten sufficient traction to get widely deployed/used.
Maybe HTTP/2.0 is a good time to try fix that.


Well, we have an existing authentication framework. It would be
interesting to find out what's missing from it.


session support with login and logout would be good.  I know it's a can 
of worms, with some serious security implications.


But this is why no websites use HTTP auth to speak of, which makes it 
difficult to do integrated authentication.


Adrien
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[David Morris]

On Wed, 22 Feb 2012, Julian Reschke wrote:

> On 2012-02-22 08:04, David Morris wrote:
> > 
> > 
> > On Tue, 21 Feb 2012, Michael Richardson wrote:
> > 
> > > 
> > > > > > > > "Barry" == Barry Leiba  writes:
> > >  Barry>  OAuth is an authorization framework, not an authentication
> > >  Barry>  one.  Please be careful to make the distinction.
> > > 
> > >  Barry>  What we're looking at here is the need for an HTTP
> > >  Barry>  authentication system that (for example) doesn't send
> > >  Barry>  reusable credentials, is less susceptible to spoofing
> > >  Barry>  attacks, and so on.
> > > 
> > > and is implemented in HTTP, not in terms of HTML forms, yet has all the
> > > flexibility of the HTML form method?
> > 
> > And includes the ability for the user to logoff / the server reset the
> > login?
> 
> Is that a protocol problem or a user agent problem?
> 
> -- > 

I consider it a protocol issue in the same way that authentication is a
protocol issue.

The question I was responding to was one of adoption by application
developers and is in addition to the lack of application control over
the current authenticate dialog. A "use case" if you will.

The JS approach isn't really adequate because not all user agents
execute the payload. Second 1/2 of the "use case."

I'm not advocating that this be solved as part of the Recharter/2.0
activity, I'm neutral on the where question.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Wes Hardaker]

> On Tue, 21 Feb 2012 23:01:09 +, Stephen Farrell 
>  said:

>> 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?

SF> Right now, I'm interested in what others reviewing the
SF> draft charter think about this topic. That's the point
SF> of having this discussion in the open like this.

IMHO, if you want security to be well integrated into the next version
of the protocol, then it should be thought about up front.  The IETF
doesn't have a great track record of adding security later to protocols
in a way that is seamless and integrated.

And if you don't put thinking about security in the "solicitation
request" charter version, then you may well end up in the state that
Mark is worried about: none of the answers have security considered.

I think the charter should definitely have a requirement indicating that
proposals must explain how security techniques would fit into it in the
future, even if they don't fully define the solution/extension itself.
-- 
Wes Hardaker
SPARTA, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Hector Santos]

Barry Leiba wrote:

browser id, openid, and oauth are all authentication frameworks built
on top of HTTP



OAuth is an authorization framework, not an authentication one.  Please be
careful to make the distinction.

What we're looking at here is the need for an HTTP authentication system
that (for example) doesn't send reusable credentials, is less susceptible
to spoofing attacks, and so on.


Hi Barry, maybe I should review the drafts (or not), but if its hasn't
been considered, this sounds like the only way possible is with a
persistent IP connection session management concept.

I can relate it based on our PCI framework for the web server and much
of the modeling was based on our existing non-http multi-device
hosting servers already 100% based on a persistent connection IP or
line, channel.  Definitely works in areas where only one browser or
machine is allowed.

I was looking forwarding to further exploring WebSockets to possible
be part of (revitaling) this solution as well, since it work nicely
with the persistent IP concept with the backend.

On a related note, some web sites do this and I first saw it with
facebook where it knows where I am logging in from. In a recent philly
trip, I tried to log on and interestingly got a new login form where
it indicated I was at a different location. I had to verify who I was
again, if I recall via my email/login account at gmail.com.

--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Hector Santos]

Julian Reschke wrote:


And includes the ability for the user to logoff / the server reset the
login?


Is that a protocol problem or a user agent problem?

-- > 



Possibly both.

First, its a non-issue with cookie based authentication methods 
(server side fancy login forms) but it is by using a cookie condition 
can you emulate a "Logoff" concept with HTTP BASIC/DIGEST AUTH due to 
the browser current persistent nature to continue reissing 
BASIC/DIGEST authenticated credentials until a 403 is issued.


The cookie i.e. "SESSION-OVER" is required to trap/trigger/recognized 
when a 403 condition should be used upon subsequent requests.  That 
will cause the Browser to forget (either full or partially the current 
credentials). Depending on the browser, it could mean a lost of 
reusing them without typing them until the browser is completely closed.


But without a cookie, there is no logoff button concept with HTTP 
AUTH.   So the question is does HTTP AUTH requires cookies to work. 
Since it does not, if a clearing of the credentials perhaps with a new 
40x or redefinition of the existing 40x, is desired, it also has to be 
based on not requiring a cookie.


In regards to the generic problem statement Barry stated, sounds to me 
that this calls for a persistent IP session level management concept. 
 A related question is to decide who is going to be asking for the 
initial credentials, the browser or a server-side login form concept?


--
Hector Santos, CTO
http://www.santronics.com



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Julian Reschke]

On 2012-02-22 08:04, David Morris wrote:



On Tue, 21 Feb 2012, Michael Richardson wrote:




"Barry" == Barry Leiba  writes:

 Barry>  OAuth is an authorization framework, not an authentication
 Barry>  one.  Please be careful to make the distinction.

 Barry>  What we're looking at here is the need for an HTTP
 Barry>  authentication system that (for example) doesn't send
 Barry>  reusable credentials, is less susceptible to spoofing
 Barry>  attacks, and so on.

and is implemented in HTTP, not in terms of HTML forms, yet has all the
flexibility of the HTML form method?


And includes the ability for the user to logoff / the server reset the
login?


Is that a protocol problem or a user agent problem?

-- > 

Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[David Morris]

On Tue, 21 Feb 2012, Michael Richardson wrote:

> 
> > "Barry" == Barry Leiba  writes:
> Barry> OAuth is an authorization framework, not an authentication
> Barry> one.  Please be careful to make the distinction.
> 
> Barry> What we're looking at here is the need for an HTTP
> Barry> authentication system that (for example) doesn't send
> Barry> reusable credentials, is less susceptible to spoofing
> Barry> attacks, and so on.
> 
> and is implemented in HTTP, not in terms of HTML forms, yet has all the 
> flexibility of the HTML form method?

And includes the ability for the user to logoff / the server reset the 
login?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Michael Richardson]

> "Barry" == Barry Leiba  writes:
Barry> OAuth is an authorization framework, not an authentication
Barry> one.  Please be careful to make the distinction.

Barry> What we're looking at here is the need for an HTTP
Barry> authentication system that (for example) doesn't send
Barry> reusable credentials, is less susceptible to spoofing
Barry> attacks, and so on.

and is implemented in HTTP, not in terms of HTML forms, yet has all the 
flexibility of the HTML form method?

Or is that still out of scope?

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Stephen Farrell]

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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Mark Nottingham]

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?

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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Stephen Farrell]

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.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Tim Bray]

[in-line]

On Tue, Feb 21, 2012 at 2:40 PM, Mark Nottingham  wrote:
>> 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.

+1

HTTP's ability to be equipped with security technology has been
adequate, and I haven't heard much argument that its semantics were
the big obstacle to newer/better security.  Preserving its semantics
means its successor should be equally adequate.

Mnot is *understating* the risk of loading up the charter with this stuff. -T
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Mark Nottingham]

On 22/02/2012, at 9:19 AM, Stephen Farrell wrote:

> 
> Hi Julian,
> 
> On 02/21/2012 06:50 PM, Julian Reschke wrote:
>> On 2012-02-21 19:37, Stephen Farrell wrote:
>>> ...
 I believe this should be orthogonal to HTTP/2.0. Is there a specific
 thing that makes it impossible to use the existing authentication
 framework?
>>> 
>>> Who knows? We don't have a protocol on the table yet. I
>>> would imagine that some level of backwards compatibility
>>> would be a requirement of course, or at least an issue to
>>> be considered.
>>> 
>>> But the existing HTTP client authentication is also not
>>> necessarily very useful, and there have been a number of
>>> efforts to improve on that, none of which seem to have
>>> gotten sufficient traction to get widely deployed/used.
>>> Maybe HTTP/2.0 is a good time to try fix that.
>> 
>> Well, we have an existing authentication framework. It would be
>> interesting to find out what's missing from it.
> 
> Fair point.
> 
> I would wonder whether that framework could be used
> as-is if HTTP/2.0 does do away "with the of HTTP/1.x
> message framing and syntax" but I guess some equivalent
> functionality could be defined in that case.

That shouldn't affect the framework at all. At most, you'd have to define how 
to re-serialise the current syntax if you don't have a way to "tunnel" it 
(since HTTP/1.1 passthrough is required).


> 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.


> 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. 

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.

Regards,


--
Mark Nottingham
http://www.mnot.net/




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Barry Leiba]

>
> browser id, openid, and oauth are all authentication frameworks built
> on top of HTTP
>

OAuth is an authorization framework, not an authentication one.  Please be
careful to make the distinction.

What we're looking at here is the need for an HTTP authentication system
that (for example) doesn't send reusable credentials, is less susceptible
to spoofing attacks, and so on.

Barry
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Stephen Farrell]

Hi Julian,

On 02/21/2012 06:50 PM, Julian Reschke wrote:

On 2012-02-21 19:37, Stephen Farrell wrote:

...

I believe this should be orthogonal to HTTP/2.0. Is there a specific
thing that makes it impossible to use the existing authentication
framework?


Who knows? We don't have a protocol on the table yet. I
would imagine that some level of backwards compatibility
would be a requirement of course, or at least an issue to
be considered.

But the existing HTTP client authentication is also not
necessarily very useful, and there have been a number of
efforts to improve on that, none of which seem to have
gotten sufficient traction to get widely deployed/used.
Maybe HTTP/2.0 is a good time to try fix that.


Well, we have an existing authentication framework. It would be
interesting to find out what's missing from it.


Fair point.

I would wonder whether that framework could be used
as-is if HTTP/2.0 does do away "with the of HTTP/1.x
message framing and syntax" but I guess some equivalent
functionality could be defined in that case.

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?

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.)

S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Julian Reschke]

On 2012-02-21 19:37, Stephen Farrell wrote:

...

I believe this should be orthogonal to HTTP/2.0. Is there a specific
thing that makes it impossible to use the existing authentication
framework?


Who knows? We don't have a protocol on the table yet. I
would imagine that some level of backwards compatibility
would be a requirement of course, or at least an issue to
be considered.

But the existing HTTP client authentication is also not
necessarily very useful, and there have been a number of
efforts to improve on that, none of which seem to have
gotten sufficient traction to get widely deployed/used.
Maybe HTTP/2.0 is a good time to try fix that.


Well, we have an existing authentication framework. It would be 
interesting to find out what's missing from it.


Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Stephen Farrell]

On 02/21/2012 06:33 PM, Julian Reschke wrote:

On 2012-02-21 19:26, Stephen Farrell wrote:


Down below, for the proposed HTTP/2.0 work it says:

> * Reflecting modern security requirements and practices

In some earlier discussion I asked what "modern" means
there. It seems to mean at least working well with TLS,
but I'm not sure what else is meant, if anything.

In particular, I think it'd be good to try get better
(more usable, more secure etc.) HTTP authentication
defined as a built-in part of HTTP/2.0.

My initial take is that if we're not going to do this
for a major revision of the protocol, then when are we
going to do it? So I'd like to see that included.

The counter argument offered was that better HTTP
authentication is complex and probably hard to get right
and so would be better handled separately.


I believe this should be orthogonal to HTTP/2.0. Is there a specific
thing that makes it impossible to use the existing authentication
framework?


Who knows? We don't have a protocol on the table yet. I
would imagine that some level of backwards compatibility
would be a requirement of course, or at least an issue to
be considered.

But the existing HTTP client authentication is also not
necessarily very useful, and there have been a number of
efforts to improve on that, none of which seem to have
gotten sufficient traction to get widely deployed/used.
Maybe HTTP/2.0 is a good time to try fix that.

S.





...


Best regards, Julian

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Julian Reschke]

On 2012-02-21 19:26, Stephen Farrell wrote:


Down below, for the proposed HTTP/2.0 work it says:

 > * Reflecting modern security requirements and practices

In some earlier discussion I asked what "modern" means
there. It seems to mean at least working well with TLS,
but I'm not sure what else is meant, if anything.

In particular, I think it'd be good to try get better
(more usable, more secure etc.) HTTP authentication
defined as a built-in part of HTTP/2.0.

My initial take is that if we're not going to do this
for a major revision of the protocol, then when are we
going to do it? So I'd like to see that included.

The counter argument offered was that better HTTP
authentication is complex and probably hard to get right
and so would be better handled separately.


I believe this should be orthogonal to HTTP/2.0. Is there a specific 
thing that makes it impossible to use the existing authentication framework?



...


Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

[Stephen Farrell]

Down below, for the proposed HTTP/2.0 work it says:

> * Reflecting modern security requirements and practices

In some earlier discussion I asked what "modern" means
there. It seems to mean at least working well with TLS,
but I'm not sure what else is meant, if anything.

In particular, I think it'd be good to try get better
(more usable, more secure etc.) HTTP authentication
defined as a built-in part of HTTP/2.0.

My initial take is that if we're not going to do this
for a major revision of the protocol, then when are we
going to do it? So I'd like to see that included.

The counter argument offered was that better HTTP
authentication is complex and probably hard to get right
and so would be better handled separately.

While that's not an unreasonable point, my counter-counter
argument is that it doesn't seem to have worked very well
so far.

It was also argued that this charter is scoped to just
allow for selection of an initial candidate for HTTP/2.0
and there'd be another re-charter to follow based on that
selected candidate, so that discussion of specific
security features would be better done after that when
there's a specific protocol on which to do work.

My worry about that is that in practice the main
security aspects of a putative HTTP/2.0 will be very
hard to change at that point, so I'd like to see it
discussed as part of this phase of the work.

What do others think?

Thanks,
Stephen.

PS: When I say "like" above, that's what I'd personally
like, not a position that I'm adopting as a security AD.
(Alhough that'd be a fairly predictable position I guess:-)


On 02/21/2012 06:10 PM, IESG Secretary wrote:

A modified charter has been submitted for the Hypertext Transfer
Protocol Bis (httpbis) working group in the Applications Area of the
IETF.  The IESG has not made any determination as yet.  The modified
charter is provided below for informational purposes only.  Please send
your comments to the IESG mailing list (i...@ietf.org) by Tuesday,
February 28, 2012.

Hypertext Transfer Protocol Bis (httpbis)
=

Charter
Last Modified: 2012-02-09

Current Status: Active Working Group

Chair(s):
 Mark Nottingham

Applications Area Director(s):
 Pete Resnick
 Peter Saint-Andre

Applications Area Advisor:
 Peter Saint-Andre

Mailing Lists:
 General Discussion:ietf-http...@w3.org
 To Subscribe:  ietf-http-wg-requ...@w3.org
 In Body:   subscribe
 Archive:   http://lists.w3.org/Archives/Public/ietf-http-wg/

Description of Working Group


This Working Group is charged with maintaining and developing
the "core" specifications for HTTP.

The Working Group's specification deliverables are:
* A document (or set of documents) that is suitable to supersede RFC
  2616 (HTTP/1.1) and move RFC 2817 to Historic status
* A document cataloguing the security properties of HTTP/1.1
* A document that specifies HTTP/2.0 an improved binding of HTTP's
  semantics to the underlying transport.

### HTTP/1.1

HTTP is one of the most successful and widely-used protocols on the
Internet today. However, its specification has several editorial issues.
Additionally, after years of implementation and extension, several
ambiguities have become evident, impairing interoperability and the
ability to easily implement and use HTTP.

The working group will refine RFC2616 to:
* Incorporate errata and updates (e.g., references, IANA registries,
  ABNF)
* Fix editorial problems which have led to misunderstandings of the
  specification
* Clarify conformance requirements
* Remove known ambiguities where they affect interoperability
* Clarify existing methods of extensibility
* Remove or deprecate those features that are not widely implemented
  and also unduly affect interoperability
* Where necessary, add implementation advice
* Document the security properties of HTTP and its associated
  mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for
  common applications

It will also incorporate the generic authentication framework from RFC
2617, without obsoleting or updating that specification's definition of
the Basic and Digest schemes.

Finally, it will incorporate relevant portions of RFC 2817 (in
particular, the CONNECT method and advice on the use of Upgrade), so
that that specification can be moved to Historic status.

In doing so, it should consider:
* Implementer experience
* Demonstrated use of HTTP
* Impact on existing implementations and deployments

### HTTP/2.0

There is emerging implementation experience and interest in a protocol
that retains the semantics of HTTP, without the legacy of HTTP/1.x
message framing and syntax, which have been identified as hampering
performance and encouraging misuse of the underlying transport.

As such, there is an opportunity to create a new major
(non-wire-compatible) version of HTTP.

To do this, the Working Group will solicit candidates for this work from
the c