Re: [AVTCORE] Re-send:Comments on draft-ietf-avtcore-aria-srtp-06.txt

[Eric Rescorla <[e-mail]>]

Hi Roni,

It seems to me that allocating code points in a Proposed Standard document
is
an endorsement.

I realize that this seemed to many like a sensible procedure in 2010, but
I would suggest that attitudes towards cipher proliferation have changed
and we should assess this draft in light of that.

Best,
-Ekr


On Sun, Sep 7, 2014 at 7:29 AM, Roni Even <[e-mail]> wrote:

> Hi Eric,
> This document does not endorse the use of ARIA for SRTP, the usage is
> based on what the implementers will implement and the IETF have no control
> over it and does not endorse any usage here . The document registers the
> IANA code points based on RFC4568 and RFC 5226. According to RFC5226 you
> can use a non IETF document (specification required ) for the SRTP
> Protection Profile registration but need a standard track RFC for the Security
> Descriptions.Doing this work at the IETF allowed for a review of the
> usage of ARIA in SRTP instead of asking the authors to go directly to IANA
> which will lead them back to the requirement for standard track RFC.  To
> the best of my knowledge RFC 4568 and RFC 5226 do not say which security
> descriptions and which protection profile can be registers just what is
> required to registers ones. (this is not ARIA that is being standardize).I
> do not voice here my opinion about if it should be done. Just pointing out
> that this work was done based on the current procedures. If we have other
> procedures we can work accordingly in the future.  BTW: this approach was
> discussed in 2010 with Robert Sparks (RAI AD advisor to AVT WG) and Sean
> Turner (security AD at the time) when the work on ARIA started at the IETF)
> based on the ARIA authors question to the ADs (not on the mailing list).
> The work also included ARIA as informational RFC and the support for ARIA
> in TLS and CMS. The the conclusion was that because if the IANA
> registration requirements there should be a standard track RFC for the SRTP
> code points registration and it should be an AVT document (individual draft
> initially)Roni Even.
>
>
>
>
>
> *From:* Eric Rescorla [mailto:[e-mail]]
> *Sent:* 07 September, 2014 3:42 PM
> *To:* Roni Even
> *Cc:* [e-mail]; IESG
> *Subject:* Re: [AVTCORE] Re-send:Comments on
> draft-ietf-avtcore-aria-srtp-06.txt
>
>
>
>
>
>
>
> On Sat, Sep 6, 2014 at 11:07 PM, Roni Even <[e-mail]> wrote:
>
> Hi Eric,
>
> This document registers the IANA codepoints for Security Descriptions,
> DTLS-SRTP, and MIKEY. The registration procedure requires standard track
> document. ARIA itself in RFC5794 is informational.
>
>
>
> I'm not sure that that changes the situation. The question is whether the
>
> IETF should be endorsing the use of ARIA for SRTP, right?
>
>
>
>
>
>
>
> The WG agreed to have a milestone for this work.
>
>
>
> Understood. However, I don't think that precludes deciding otherwise
>
> at this point.
>
>
>
> -Ekr
>
>
>
>
>
> *From:* avt [mailto:[e-mail]] *On Behalf Of *Eric Rescorla
> *Sent:* 07 September, 2014 1:47 AM
> *To:* [e-mail]; IESG
> *Subject:* [AVTCORE] Re-send:Comments on
> draft-ietf-avtcore-aria-srtp-06.txt
>
>
>
> [Now with a right address]
>
>
>
> I just took a look at draft-ietf-avtcore-aria-srtp-06.txt and I'm trying
> to figure
>
> out why it's being advanced, especially as Standards Track. I have two
>
> concerns:
>
>
>
> 1. The arguments for specifying ARIA at all seem to be fairly weak. I
>
> went back to the mail archives and found my question about this from
>
> 2012, where I asked why we needed ARIA given that we have already
>
> standardized one KISA algorithm (SEED).
>
>
>
> http://www.ietf.org/mail-archive/web/avt/current/msg15603.htm
>
>
>
> The answer, apparently, is that the Korean government wants it:
>
> http://www.ietf.org/mail-archive/web/avt/current/msg15632.html
>
>
>
>  Both SEED and ARIA were established as KS(Korean Standard) by the
>
>  Ministry of Knowledge Economy of Korea.  But SEED and ARIA have
>
>  different application areas each other.  While SEED is mainly used
>
>  for for electronic commerce and financial service, ARIA is for
>
>  government use and public purpose.  As the governmental area is
>
>  growing recently, we need to standardize SRTP-ARIA even though
>
>  SRTP-SEED is already defined in RFC 5669.
>
>
>
> Substantively, standardizing a cipher just because a national government
>
> wants to use it doesn't seem like a really great idea.
>
>
>
> I just went back through the mailing list and was unable to find any
>
> messages that argued for standardizing ARIA other than those that
>
> appear to be by the authors. Procedurally, this doesn't really seem
>
> like the level of support that we should be looking for, especially
>
> for a standards track document.
>
>
>
>
>
> 2. If we are to specify ARIA, we shouldn't be specifying the combinatoric
>
> explosion of all the key lengths and cipher modes. Rather, we should
>
> specify GCM with one authentication tag and one or two key sizes.
>
> In response to my comments above, the authors argued that they were
>
> looking for parity with AES, but this isn't a good reason, since AES is
>
> the algorithm we are actually encouraging people to use (and even there
>
> it would be better to have fewer modes). In TLS we are trying to move
>
> away from non-AEAD ciphers and SRTP should probably do the same.
>
>
>
> -Ekr
>
>
>