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

["Roni Even" <[e-mail]>]

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:[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