Subject: Re: Security Requirements for HTTP, draft -00

From: Robert Sayre <[email-masked]>
Date: Sun, 03 Feb 2008 06:11:22 +0000

> Not even close.  Regular old HTTP authentication requests outnumber
> browser-driven forms-based use of the Web (on a per request basis)
> by an order of magnitude.

I agree that the draft is skewed towards browser-like use cases, and  
some statements don't apply to automated traffic. I also think browser- 
like traffic is where HTTP authentication as currently implemented is  
pretty useless, and worth focusing on.

>
> The opinions stated in the draft are wrong and do nothing but obscure
> the mechanisms that are supposed to be described.

Disagree. The purpose of the draft is not to describe the mechanisms  
in high detail. It's also OK to have unsubstantiated claims in a  
working document, as long as they are taken care of before  
publication. Removing the quantitative claims would probably avoid a  
lot of boring finger wagging IETF mail, so I agree they should go.

>  I suggest you remove
> them and rely more on actual examples of authentication as used in  
> HTTP.

One concrete data point would be that Amazon AWS traffic (some of  
which uses their custom HTTP auth scheme) has surpassed the traffic of  
Amazon.com. OTOH, it might be that more GET requests to Amazon.com are  
FBA-customized, while most of the GET requests to AWS are not  
authenticated. Would love some actual data.

> A lot of the stuff heard at an IETF meeting is simply old wives tales
> retold by folks who don't build application services, let alone the
> services that use HTTP.  They should not be relied upon for this  
> draft.

That isn't the source material for this document, but I'm glad you  
enjoy the meetings.

To me, HTTP authentication is the stuff that's ineffectively presented  
in the browser, but not worth fixing, because the existing schemes  
aren't useful. The draft is trying to determine why that is.

> It doesn't make any difference either way.  The notion that
> authenticated HTTP requests are almost entirely based on FBA is  
> absurd.
> It ignores the fact that most HTTP requests aren't even made by  
> browsers.

Yes, there may be a large amount of traffic using HTTP Authentication  
in applications that are difficult to observe. They might even get  
good scalability, compatibility, and security properties from it. I  
don't care about them, but I don't object to language that makes their  
existence known.

- Rob

---

From: "Mike Dierken" <[email-masked]>
Date: Sun, 3 Feb 2008 12:20:25 -0800

Would it be helpful to group the security requirements in the document into
'browser-like' use cases and 'automation-like' use cases and ensure that
both sets are considered consistently?

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Robert Sayre
Sent: Saturday, February 02, 2008 10:11 PM
To: [email-masked]
Subject: Re: Security Requirements for HTTP, draft -00

I agree that the draft is skewed towards browser-like use cases, and some
statements don't apply to automated traffic. I also think browser-like
traffic is where HTTP authentication as currently implemented is pretty
useless, and worth focusing on. 

Disagree. The purpose of the draft is not to describe the mechanisms in high
detail. It's also OK to have unsubstantiated claims in a working document,
as long as they are taken care of before publication. Removing the
quantitative claims would probably avoid a lot of boring finger wagging IETF
mail, so I agree they should go.

 I suggest you remove
them and rely more on actual examples of authentication as used in HTTP.

One concrete data point would be that Amazon AWS traffic (some of which uses
their custom HTTP auth scheme) has surpassed the traffic of Amazon.com.
OTOH, it might be that more GET requests to Amazon.com are FBA-customized,
while most of the GET requests to AWS are not authenticated. Would love some
actual data. 

A lot of the stuff heard at an IETF meeting is simply old wives tales
retold by folks who don't build application services, let alone the
services that use HTTP.  They should not be relied upon for this draft.

That isn't the source material for this document, but I'm glad you enjoy the
meetings.

To me, HTTP authentication is the stuff that's ineffectively presented in
the browser, but not worth fixing, because the existing schemes aren't
useful. The draft is trying to determine why that is.

It doesn't make any difference either way.  The notion that  
authenticated HTTP requests are almost entirely based on FBA is absurd.
It ignores the fact that most HTTP requests aren't even made by browsers.

Yes, there may be a large amount of traffic using HTTP Authentication in
applications that are difficult to observe. They might even get good
scalability, compatibility, and security properties from it. I don't care
about them, but I don't object to language that makes their existence known.

- Rob

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 3 Feb 2008 13:47:31 -0800

At 12:20 PM -0800 2/3/08, Mike Dierken wrote:
>Would it be helpful to group the security requirements in the 
>document into 'browser-like' use cases and 'automation-like' use 
>cases and ensure that both sets are considered consistently?

I think so.

--Paul Hoffman, Director
--VPN Consortium