Re: security requirements

Paul,

it's good to shed some light on the history and how it came all into  
being.

I think we all can agree that a suitable MTI security in HTTP would  
be a good thing. The problem is that current analysis by several  
people indicates that there is not such authentication scheme  
available right now. If it would, the debate could start which  
process to use in what spec and protocol revision that could best be  
incorporated.

But the current approach seems to talk about processes and barriers  
to spec revisions before that technical solution even has surfaced.  
Spec writers, putting often their spare time into this, feel  
frustrated. It seems that they either have to include some mumbo- 
jumbo into their spec which not everyone implementing the  spec is  
able to follow or shall fix the whole HTTP MTI security issue.

I feel this is wasting energy on both sides without giving any  
tangible results.

Cheers,

Stefan

Am 20.10.2006 um 11:04 schrieb Paul Leach:

>
> I don't think the IETF bashing is warranted. They made a mistake in  
> not
> requiring us to specify an MTI security mechanism in 2617 (and in  
> having
> 2616 require that a conformant implementation support 2617). There was
> no tacit agreement by some "in-crowd" that we didn't have to live  
> by the
> rules.
>
> As I indicated in an earlier post, perhaps it was the prevalence of
> legitimate anonymous access with HTTP that caused this oversight.  
> Given
> the to-do raised by Mr. Sayre recently, I doubt that anyone doing
> HTTP/1.2 will have to worry about (or could count on) a similar
> oversight :-)
>
> Historically, the rules evolved because for a long time most protocol
> designers totally ignored security -- throwing in plain-text passwords
> at best. Hence the requirement to have non-plaintext-password
> authentication, and security considerations sections. The notion of  
> MTI
> actually is totally independent of security -- it is a general  
> principle
> of protocol design for any protocol that has options, in order to
> guarantee that conforming implementations can always be configured to
> interoperate. (This was in reaction to the ISO protocol mess with
> non-interoperable "profiles" of the 1980's.)
>
>

Received on Friday, 20 October 2006 09:24:10 UTC