Subject: [saag] Cipher suite proliferation

From: Sean Turner <[email-masked]>
Date: Fri, 27 Aug 2010 15:21:30 -0400

At SAAG, I gave a short presentation about how Tim and I were thinking 
about a change to what track we put "how to use those algorithms with 
a particular protocol" drafts: 
http://www.ietf.org/proceedings/78/slides/saag-4.pdf.  I'd like to 
hear the community's thoughts on whether we should continue with the 
status quo or whether we should make a change (see below).

The current status quo is for the algorithm documents to go on the 
informational track and for the how to use algorithm x with protocol y 
on standards track.

Recently, at least one WG has declined to adopt as WG items drafts 
that specify how to use algorithm x with their particular protocol. 
Obviously, the authors then come to the ADs.

Tim and I have been thinking that most of these drafts should go on 
informational.  We thought that the following would be how we'd decide 
what track to put a draft on:

1) Submit an individual I-D documenting the how to use algorithm x 
with protocol y (document the cryptographic algorithm somewhere else).

2) Ask the WG for adoption.  If the answer is no, then jump to #5.

3) Proceed as WG document.  WG selects and requests the track.

4) AD processes the document normally.  In general, this means 
progressing on the requested track.  If the WG proposed standards 
track, then the AD will consider whether there is broad international 
support, there is a need, and there are implementations. The AD may 
decide to request publication as Informational if support is not broad 
support, there is no need, and if there are no implementations.

5) Authors ask for AD sponsorship of I-D.

6) AD will ask the following question: Is there broad international 
support, is there a need, and are there implementations?  If the 
answer is no, then jump to #8.

7) AD will sponsor the document for publication on standards track.

8) AD will sponsor the document on either informational or 
experimental track.

We'd like to hear whether we should keep the status quo (either 
because you like it or think we're making a mountain out of mole hill) 
or whether the steps above should be used.

Thanks,

spt

---

From: Yoav Nir <[email-masked]>
Date: Fri, 27 Aug 2010 23:47:58 +0300

Hi Sean

In most cases, I think steps 2-5 are superfluous.  I don't think the working group has much to contribute.

If I submit a draft called "ROT13 and its use in IPsec", assuming that an informational RFC already exists for ROT13, there's really very little for the working group to do. They can't change ROT13, and they wouldn't want to.  There's usually very little interaction between the protocol and the algorithm. Of course there are some things to consider, like how big the IV is for ROT13, and what kind of padding is required, but I think the high road should be getting it published as an individual. IOW, unless there's some very unique interaction between the algorithm and the protocol, the authors shouldn't need to ask the WG for adoption. Instead, the authors go straight to the AD, and the AD asks on the protocol mailing list whether people there think this should go through the WG.

Yoav

On Aug 27, 2010, at 10:21 PM, Sean Turner wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
> 
> Scanned by Check Point Total Security Gateway.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 28 Aug 2010 21:41:52 -0700

I agree with Yoav -- these kind of documents should in most cases be informational.  

In general, I do not feel that ADs should be sponsoring a large number of Standards Track documents outside of WGs.  The situation where there is widespread international interest, and yet no WG exists or can be created to handle the item seems like a contradiction.  Something is badly broken if this becomes a regular occurrence (as it seems to have).  Either we have IANA allocation policies that require standards documents in situations where this should not  be necessary, or we are rewarding behavior that should be discouraged. 

> From: [email-masked]
> To: [email-masked]
> Date: Fri, 27 Aug 2010 23:47:58 +0300
> CC: [email-masked]
> Subject: Re: [saag] Cipher suite proliferation
> 
> Hi Sean
>

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 30 Aug 2010 00:59:35 +0100

I tend to agree with Bernard on the argument that standards track docs
should be in WGs. (reasoning "international interest/need/multiple
implementations => WG involvement")

In general obviously protocols should be specified with algorithm
agility (algorithms can be replaced easily, e.g. load by
name/identifier). In a perfect case (if the parameter interface is
interchangeable) this would mean you wouldn't even need an info doc for
how to use it in the specific protocol and only need the algorithm info
doc. However in the real world we know new algorithms frequently require
certain interpretation of fields in the protocol which can be done in a
short and simple info document. In which case it definitely would be
good to ask the WG for review (so that you don't get
(mis-)interpretation conflicts) and if the WG declines to adopt this
item for any other reasons than time/resource constraints (which
wouldn't be a good reason) the AD should consider to send the authors
back to the WG to sort things out.

To talk about the process: this would replace step #7 with:
7) AD will ask the authors (and WG) the following question: Then why has
the WG rejected to adopt the document and are there ways to mitigate
these reasons so that it will be adopted? If yes go back to 3) otherwise
consider informational status, rejection or under special circumstances
make exception and AD will sponsor the document for publication on
standards track.

just my 5 cents, Tobias

On 08/29/2010 05:41 AM, Bernard Aboba wrote:
> In general, I do not feel that ADs should be sponsoring a large number
> of Standards Track documents outside of WGs.  The situation where
> there is widespread international interest, and yet no WG exists or
> can be created to handle the item seems like a contradiction. 
> Something is badly broken if this becomes a regular occurrence (as it
> seems to have).  Either we have IANA allocation policies that require
> standards documents in situations where this should not  be necessary,
> or we are rewarding behavior that should be discouraged.
>
>
> > If I submit a draft called "ROT13 and its use in IPsec", assuming
> that an informational RFC already exists for ROT13, there's really
> very little for the working group to do. They can't change ROT13, and
> they wouldn't want to. There's usually very little interaction between
> the protocol and the algorithm. Of course there are some things to
> consider, like how big the IV is for ROT13, and what kind of padding
> is required, but I think the high road should be getting it published
> as an individual. IOW, unless there's some very unique interaction
> between the algorithm and the protocol, the authors shouldn't need to
> ask the WG for adoption. Instead, the authors go straight to the AD,
> and the AD asks on the protocol mailing list whether people there
> think this should go through the WG.
> >
> > Yoav
> >
> >