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

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

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