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

From: RJ Atkinson <[email-masked]>
Date: Wed, 22 Feb 2012 12:01:47 -0500

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 23 Feb 2012 17:13:21 +0100

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

> then that work will not happen at all.

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

> needs to be designed-in, not bolted-on later.

I would say: security needs to be orthogonal.

> 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

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 23 Feb 2012 12:59:15 -0500

> 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

---

From: Leif Sawyer <[email-masked]>
Date: Thu, 23 Feb 2012 09:00:29 -0900

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: [email-masked] [[email-masked]] On Behalf Of RJ Atkinson [[email-masked]]
Sent: Thursday, February 23, 2012 8:59 AM
To: [email-masked]
Subject: Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Yours,

Ran

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Doug Barton <[email-masked]>
Date: Thu, 23 Feb 2012 14:33:25 -0800

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

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/

---

From: Tim Bray <[email-masked]>
Date: Thu, 23 Feb 2012 14:35:23 -0800

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 23 Feb 2012 23:42:09 +0100

> 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