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

From: Eric Rescorla <[email-masked]>
Date: Sat, 6 Sep 2014 15:46:30 -0700

[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

---

From: "Roni Even" <[email-masked]>
Date: Sun, 7 Sep 2014 09:07:12 +0300

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.

The WG agreed to have a milestone for this work.

Roni Even

From: avt [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: 07 September, 2014 1:47 AM
To: [email-masked]; IESG
Subject: [AVTCORE] Re-send:Comments on draft-ietf-avtcore-aria-srtp-06.txt

I just took a look at draft-ietf-avtcore-aria-srtp-06.txt and I'm trying to figure

concerns:

 

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Sep 2014 05:42:12 -0700

On Sat, Sep 6, 2014 at 11:07 PM, Roni Even <[email-masked]> 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?

Understood. However, I don't think that precludes deciding otherwise
at this point.

-Ekr

>
> *From:* avt [mailto:[email-masked]] *On Behalf Of *Eric Rescorla
> *Sent:* 07 September, 2014 1:47 AM
> *To:* [email-masked]; IESG
> *Subject:* [AVTCORE] Re-send:Comments on
> draft-ietf-avtcore-aria-srtp-06.txt
>
>
>

---

From: Barry Leiba <[email-masked]>
Date: Sun, 7 Sep 2014 16:18:53 +0300

> IETF should be endorsing the use of ARIA for SRTP, right?

Put another way, the registration policy is Standards Action for a reason,
not just to make someone write a Standards Track RFC.  The point is to make
us think about whether Standards Track is appropriate, and to give it
commensurate review as Eric is doing).

There is the other question of whether it's better to register what will be
in use, even if we don't endorse it as a standard.   But the right approach
if the answer to that is "yes" is not to write more standards that we don't
really endorse, but to change the policy so it accurately reflects how we
want things to get registered.

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 07 Sep 2014 14:36:44 +0100

> commensurate review as Eric is doing).

Right. And I've gotta say I've a lot of sympathetic for Eric's point.
Adding more algorithms for fun, is not fun. Each has a non-trivial
cost both in terms of engineering/test for developers, and in
terms of potential damage to interop if some set of implementations
end up with no common good algorithms.

> want things to get registered.

The "what will be in use" point gets harder to evaluate
for national-specific algorithms like this. If something is in
widespread use over the Internet that's one thing, but for ARIA
as far as I know we really are dealing with something that's
only in use in one country (to the extent that it is) and maybe
otherwise as "leakage" (as camellia once was in firefox for
example). While I would not say that "in use in one country" is
never sufficient, I definitely do think that country-specific
stuff is far less convincing that stuff that's gotten much broader
acceptance.

>From all that one might reasonably conclude that we ought
expect/demand noticeable non-proponent backing for national
algorithms before putting them on the standards track.

That is my conclusion anyway FWIW. And its one that I think
also does have support from many security folks, though
without having specifically tested for it, I do not claim we'd
definitely have rough consensus on exactly that amongst
security folks nor in the IETF more broadly.

S.

---

From: "Roni Even" <[email-masked]>
Date: Sun, 7 Sep 2014 17:29:58 +0300

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:[email-masked]] 
Sent: 07 September, 2014 3:42 PM
To: Roni Even
Cc: [email-masked]; IESG
Subject: Re: [AVTCORE] Re-send:Comments on draft-ietf-avtcore-aria-srtp-06.txt

Hi Eric,

 

at this point.

-Ekr

concerns:

 

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Sep 2014 13:30:05 -0700

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 <[email-masked]> 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:[email-masked]]
> *Sent:* 07 September, 2014 3:42 PM
> *To:* Roni Even
> *Cc:* [email-masked]; IESG
> *Subject:* Re: [AVTCORE] Re-send:Comments on