headers
Sam Hartman | 10 Feb 2006 02:00
Picon
Favicon

BCP 61, advancing to draft


Hi.  I'd like to remind everyone of BCP 61.  It says roughly that
protocols we approve need a mandatory to implement security mechanism.
We here in the security area think that's a great idea.  O, by the
way, we're here to help you.

As part of our plan for world domination^h^h^hhelping you, we've
created a number of security solutions including things like SASL,
TLS, IPsec, Kerberos, GSS-API, and CMS.  We really like it when you
use these security services instead of inventing your own.  First, it
makes it hugely easier for us to review your documents.  Second, it
makes it easier when we need to do algorithm upgrades to things like
hash functions or replace DES with AES.  Finally it probably makes
your security easier to deploy.

There's this littple problem though.  All of the above are at proposed
standard.

For a number of reasons they are not moving to draft as soon as anyone
would like.

So, I see two options that I don't like.  First, we can avoid security
in anything going to draft.  Draft becomes a dumping ground for all
the older protocols (plus a few things like SNMP that invent their own
security) without updates that add security.  Secondly, we can block
everything from going to draft.

Does anyone want to work on a better answer to this?

--Sam
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald Tveit Alvestrand | 10 Feb 2006 10:02
Picon

Re: [saag] BCP 61, advancing to draft


--On 9. februar 2006 20:00 -0500 Sam Hartman <hartmans-ietf <at> MIT.EDU> wrote:

> As part of our plan for world domination^h^h^hhelping you, we've
> created a number of security solutions including things like SASL,
> TLS, IPsec, Kerberos, GSS-API, and CMS.  We really like it when you
> use these security services instead of inventing your own.  First, it
> makes it hugely easier for us to review your documents.  Second, it
> makes it easier when we need to do algorithm upgrades to things like
> hash functions or replace DES with AES.  Finally it probably makes
> your security easier to deploy.
>
>
> There's this littple problem though.  All of the above are at proposed
> standard.
>
> For a number of reasons they are not moving to draft as soon as anyone
> would like.

Care to elaborate?

> So, I see two options that I don't like.  First, we can avoid security
> in anything going to draft.  Draft becomes a dumping ground for all
> the older protocols (plus a few things like SNMP that invent their own
> security) without updates that add security.  Secondly, we can block
> everything from going to draft.
>
> Does anyone want to work on a better answer to this?

Seems that there are two possible answers:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Hartman | 10 Feb 2006 13:34
Picon
Favicon

Re: [saag] BCP 61, advancing to draft

>>>>> "Harald" == Harald Tveit Alvestrand <harald <at> alvestrand.no> writes:

    >> 
    >> For a number of reasons they are not moving to draft as soon as
    >> anyone would like.

    Harald> Care to elaborate?

Sure, but this is very much with my AD hat off and with the warning
that I'm probably wrong on some of these.

SASL: internationalization issues; low number of volunteers dedicating
time.  Not clear which mechanism to move to draft to validate the framework.

IPsec: just moved to proposed again; not many implementations; already
needs for clarifications drafts.

TLS: Moving to proposed again because of hash mess.

Kerberos: Doable, but we're all fairly busy working on meeting new
customer needs.  We did recently hold a meeting and develop feature
matrix and roughly what we'd need to remove from the spec.  We were
really hoping that RFC 4120 would not need things removed; I think a
lot of us lost interest in moving Kerberos to draft any time soon when
we found out that was not the case.

GSS-API: Needs a mechanism to move to drfat.  Kerberos mechanism
depends on Kerberos.  Everything else needs some significant work on
the documentation front that no one is really chartered to do.  An
individual wanted to do the work and was encouraged to contact an AD
(Continue reading)

Permalink | Reply | 0 comments |
headers
RJ Atkinson | 10 Feb 2006 14:06
Favicon

Re: [saag] BCP 61, advancing to draft


On  10 Feb 2006, at 04:02, Harald Tveit Alvestrand wrote:
% Seems that there are two possible answers:
%
% - Move the security stuff to Draft (knocking down the reasons for that
% not happening one at a time, possibly changing the criteria for Draft
% on the way)
% - Abolish Draft
%
% I consider the third option - having Draft with downreference to
Proposed -
% to be a Bad Idea. If we have to do that, I'd rather abandon Draft.

I would suggest that in parallel both (1) "move the security stuff to
Draft"
and (2) "abolish Draft Standard" of Harald's suggestions be undertaken.

My guess is that Sam's note was a polite way of trying to "encourage"
the security community to undertake (1), but I could be wrong.

Security is not the only thing that impedes going to Draft Standard
or Full Standard.  There is a longish list of things that can impede
progression away from Proposed Standard.  We have an impressive number
of IETF standards-track protocols that have been at Proposed Standard
for many many years.  Some are widely used, while others are widely
ignored.

My proposal for a new standards track looks roughly like this:

1) Proposed Standard
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 10 Feb 2006 14:13
Picon
Picon
Picon
Favicon

Re: [saag] BCP 61, advancing to draft

Sam Hartman <hartmans-ietf <at> MIT.EDU> writes:
>>>>>> "Harald" == Harald Tveit Alvestrand <harald <at> alvestrand.no> writes:
>   >>
>   >> For a number of reasons they are not moving to draft as soon as
>   >> anyone would like.
>
>    Harald> Care to elaborate?
>
>Sure, but this is very much with my AD hat off and with the warning that I'm
>probably wrong on some of these.
>
>[List snipped]

Just looking at this list, is the document-status thing just a case of
changing some policy, or is there more to it than that?  For example from that
list TLS, Kerberos, and CMS have all been around for 10-15 years so it's
unlikely that there are going to be major changes in the spec, and in
particular that there will be non-backwards-compatible changes.  So all you'd
need to do is instead of pointing to [RFCxxxx], point to [TLS], where [TLS] is
"'The TLS Protocol', version 1.1 or any later version".  This is already done
by documents like the GPL, which specify use of "version X or any later
version" rather than hardcoding in a particular document.  Since these
protocols stick around for years, even decades (I mean we've only just got
around to deprecating the broken SSLv2 protocol after 12 years of use), I
can't see any major interop problems turning up.  Without this, you end up
with horrible priority inversions where some far-distant unfinished spec ends
up blocking a major standards effort that needs to refer to it.

Peter.
.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven M. Bellovin | 10 Feb 2006 14:29

Re: [saag] BCP 61, advancing to draft

In message <7DBC3359-383A-4A2B-BF37-8D9A63DA4526 <at> extremenetworks.com>, RJ Atkin
son writes:
>
>
>
>> TLS: Moving to proposed again because of hash mess.
>
>I'd suggest pushing on this one first in a focused way.  The hash
>situation should be very straight-forward to sort out, if the ADs
>apply time pressure to the group.  Adding new hash functions is
>not technically difficult, though IETF processes can be very difficult
>these days.

The issue is not adding the hash functions, it's adding the negotiation
to permit their use.

 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

.
Permalink | Reply | 0 comments |
headers
RJ Atkinson | 10 Feb 2006 14:21
Favicon

Re: [saag] BCP 61, advancing to draft


On  10 Feb 2006, at 07:34, Sam Hartman wrote:
> Sure, but this is very much with my AD hat off and with the warning
> that I'm probably wrong on some of these.
>
> SASL: internationalization issues; low number of volunteers dedicating
> time.  Not clear which mechanism to move to draft to validate the
> framework.

So the issue here is multiple-dependency:
 	- SASL can't advance because of the I18N rules
 	- lots of other stuff can't advance because of SASL

I'd say that the thing to do is to waive the I18N rule to
let SASL go to Draft (with a requirement that I18N issues
get addressed before further forward motion) -- then push
on the I18N portion of the IETF to pitch in on this.

I'm familiar with several languages and from time to time (e.g. MIME)
have been involved in I18N discussions in the IETF.  However, a big
percentage of the IETF are only familiar with one or two languages
(polyglots are actually rare in our circles).  Those familiar with
only one language are not likely to be able to help very much.

> IPsec: just moved to proposed again; not many implementations; already
> needs for clarifications drafts.

One only needs 2 interoperable implementations to move to Draft
Standard.
If the new spec(s) don't have that, push the implementers to sort out
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Gutmann | 10 Feb 2006 14:33
Picon
Picon
Picon
Favicon

Re: [saag] BCP 61, advancing to draft

RJ Atkinson <rja <at> extremenetworks.com> writes:
>> PKIX: I think has some internationalization issues; possibly some hash
>> fun.  Not really sure.
>>
>> CMS: Unsure.  Wouldn't surprise me if besides PKIX dependencies this
>> was in the best shape.
>
>These also don't look like low-hanging fruit.
>
>I think TLS is probably the lowest hanging fruit here.  IPsec, Kerberos, and
>SASL come next in a clump.  GSS-API, PKIX, and CMS seem pretty high up the
>tree just now.

And that's the problem - CMS and TLS are both blocked waiting on PKIX (this is
what held up TLS at the RFC 2246 stage for what, three years?).  Presumably
IPsec will also block on PKIX.  This is why I proposed the relative- rather
than absolute-value reference approach in my previous message.  Without this,
you get the priority-inversion situation of the lowest-hanging fruit stalled
behind the highest-hanging fruit (not to mention appallingly mangled
metaphors).

Peter.
.
Permalink | Reply | 0 comments |
headers
Kurt D. Zeilenga | 10 Feb 2006 16:20

Re: [saag] BCP 61, advancing to draft

I note that just because some dependencies are not yet
ready to be progressed to Draft Standard doesn't preclude
us from revising protocols as needed to address other
issues holding them at Proposed.  For instance, with
LDAP, we've resolved a host of issues requiring publication
of revised LDAP specifications.  These will get published
at Proposed in conjunction with revised TLS and SASL specs,
then pending implementation reports and other requirements,
we should get to Draft.

I also note that the formal Draft Standard declaration
is not nearly as important as resolution of the technical
issues that kept us at Proposed.  As these issues have been
adequately addressed, I'm quite happy.  The formalities
will catch up in due course.

That is, I really don't see a problem here. 

Kurt

At 05:00 PM 2/9/2006, Sam Hartman wrote:

>Hi.  I'd like to remind everyone of BCP 61.  It says roughly that
>protocols we approve need a mandatory to implement security mechanism.
>We here in the security area think that's a great idea.  O, by the
>way, we're here to help you.
>
>As part of our plan for world domination^h^h^hhelping you, we've
>created a number of security solutions including things like SASL,
>TLS, IPsec, Kerberos, GSS-API, and CMS.  We really like it when you
(Continue reading)

Permalink | Reply | 0 comments |
headers
RJ Atkinson | 10 Feb 2006 15:08
Favicon

Re: [saag] BCP 61, advancing to draft


On  10 Feb 2006, at 08:33, Peter Gutmann wrote:
> And that's the problem - CMS and TLS are both blocked waiting on
> PKIX (this is
> what held up TLS at the RFC 2246 stage for what, three years?).

> Presumably IPsec will also block on PKIX.

ESP/AH do not depend on PKIX, and they ought not normatively depend
on IKE (or any other automatic key management method), so ESP/AH
should be able to move forward without PKIX.  Similarly, applications
that use ESP/AH, should be able to move forward when ESP/AH move
forward,
regardless of IKE (or PKIX).

The modular design of ESP/AH/ISAKMP/IKE was very deliberate -- because
the original designer of ESP/AH fully expected that the key management
schemes would need to change (given the past history of Diffie-Hellman
and Needham-Schroder in the published history up through 1995).

Cheers,

Ran
.
Permalink | Reply | 0 comments |

Gmane