[AVTCORE] FW: Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) - CCM as MTI?

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

Hi,
The document has been in IESG review and there is an open discuss about the
need for CCM as MTI.
Since this has not been discussed on the AVTcore mailing list we have only
response from David McGrew who is one of the authors.
The discuss thread is given bellow

The open question is if we want to keep CCM as MTI, make CCM optional or
remove it from the document.
 I will appreciate any opinion so we can decide on way forward


BTW; the original discuss is also
https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ballot/ but
the issue to address is the need for CCM?

Thanks
Roni Even





Hi Kevin,

Following your format:

1a) I could buy both 128 and 256 being defined 1b) AFAIK CCM is
in other protocols mainly due to IEEE h/w that can only do CCM,
if that doesn't apply here (and why would it?) then I think GCM
only should work 1c) goes away if you ditch CCM:-)

2) As per above, ditch CCM and its all easy:-)

So - do we have real reasons to need CCM for this?


CCM is preferable when short authentication tags are used,
because it is less vulnerable to repeat-forgery attacks.   If I
remember right, I'm the person that put CCM there, and that's
why.   My experience with SRTP users makes me think that some
will go for the shortest tag possible, and we should avoid
security issues (and even the perception of security issues).


So my question is whether all the options introduced as a direct 
result vs. that "less vulnerable" difference is really a good
trade off if the complexity means that a bunch of folks won't use
any of this.


I think it is worthwhile to keep those definitions.   The additional
implementation work for the longer CCM tags is not much (assuming
that we use CCM for a short tag).



Do we have anyone who would scream if CCM were taken out for 
example? If not, isn't that, and the fact that CCM could be added
later if really needed, indicative that taking it out now would be
better?



Another fair question to ask is: do we have anyone saying "I won't
implement this specification unless CCM is removed"?


Is that really as good a question? Isn't taking things out until
no more can be taken out a better design principle?



Granted, my question isn't really based on any technical argument.   I asked
it in response to your comment "if the complexity means that a bunch of
folks won't use any of this".   I had not heard anyone object to the
complexity of including CCM in SRTP, so I was genuinely wondering.





It is important that we don't dismiss the effort required to have CCM
"added later"; 


That's outweighed significantly by implementer effort, 


I think you misunderstand my meaning here.   In any case, if CCM were listed
as optional, that would impose no cost implementers who didn't want CCM,
while retaining the normative definition.


and much
moreso with CC/FIPS eval.



Sorry, I don't understand about the CC/FIPS issue.   Maybe I missed
something, it is not a big deal to me.




look how much time and effort has gone into the
current draft.   If people are really against having CCM being
mandatory to implement, then CCM could be described as "optional" or
something like that.   But there is a lot of value in retaining the
normative definitions as they have been crafted.

To answer your question: I don't know anyone who would scream if CCM
was taken out, except that there are people that want 8 byte
authentication, and other people that think GCM should never be used
for 8 byte authentication.


Do we have list traffic to that effect? Be interested in pointers if
so.



On the need for short tags: SRTP currently allows four-byte HMAC
authentication, and many people using that length will not want to move to
eight, much less 16.   There was discussion on the AVT list in the year
before RFC 3711 was published. I know at least one person who will use the
shortest tag length that the SRTP standard allows.   I bet that asking on
the AVTCORE list would reveal people who favor minimal overhead, who care
most about VoIP, and VoIP over wireless.


On the inapplicability of GCM for short authentication tags: see for
instance Procter and Cid "On Weak Keys and Forgery Attacks against
Polynomial-based MAC Schemes".   If bet that asking on the CFRG list would
get at least one person who would say that GCM should not be used with
8-byte tags.  


David



Meanwhile, I'll think on it some more - I don't like the added options,
but if I'm alone in that, then I'll likely get out of the way. As of
now, I'm not sure if I'm alone in that or not.


On 29/10/14 20:41, Igoe, Kevin M. wrote:



On 20 October Stephen Farrell wrote:



Before I move to a yes ballot, I want to chat about two 
things...



(1)There are perhaps too many choices being offered here to
be useful. It is very possible so much choice can harm
interop and hence security.

a)  Do we *need* the 256 bit key options now?

b)  Is CCM really *needed* here? (Surprised the IEEE or h/w 
argument applies tbh)

c)  And why so many auth. tag lengths?

Who really *needs* all of those? The DISCUSS point here is
to validate that all of those options really *need* (as
opposed to can) be defined, which may have been done already
or may (and we have seen this) simply be a case of defining
everything in the hope that something gets used. That can
cause potential harm to interop. if different coders pick up
different options. And the "but the USG will use all of
these" is not IMO a sufficiently good argument for defining
all of them - we also have experience with PKI that adding
every option that the most complex deployments may want is
not the recipe for success (e.g. with enrolment protocols).



(2) Unless discuss point (1) results in there being only one 
remaining option, (which I doubt:-), which of the options 
specified here are MTI, and if you argue that that needs to
be done elsewhere, then where will that be done? (We already
had a major extended discussion about SRTP MTI things in
general.) I would suggest that saying something like "128 bit
GCM with a tag length of 16 MUST be implemented by any
general purpose implementation of this specification" or
something similar.


1.a (key sizes):

Quoting chapter and verse, the NSA Mobility Capability
Package, which can be found at 
https://www.nsa.gov/ia/_files/Mobility_Capability_Pkg_Vers_2_0.pdf,







lays out a requirement for a Suite B compliant implementation of SRTP.

You'll

be shocked to hear that my primary goal is supporting that 
requirement.  The corresponding Mobile Fundamentals
Protection Profile:
https://www.niap-ccevs.org/pp/pp_md_v2.0.pdf contains the
requirement for 256-bit key sizes after September 2015. So 
basically, both 128 bits (for the typical user) and 256 bits
(for the truly paranoid user) are either being used now or
will be used in the near future.





1.b. (Both GCM and CCM)



You can probably tell from the title of the I-D what my
personal preference

is on this issue.  But I haven't been appointed crypto czar,
and in other protocols people I consider to be rational
professionals have expressed a preference for CCM over GCM.
Also, as mentioned below, only CCM can support the shortest
allowable tag size (8 bytes).





1.c. (tag sizes)



We can't have a "one size fits all" solution for SRTP due to
the inherent conflict between latency and security.  I put in
a table

in section 14.2 (which I'm certain is a paragon of clarity) 
laying

out the various options.  The level or risk (probability of
a

compromise) is very much dependent upon the application -
some times

the authentication is protecting a service of little value
but one

where even a single byte of additional data has a measurable 
impact,

and sometimes the service being protected is of
extraordinary value

and the cost of a few more bytes of data [ales in
comparison.

byte of data impacts your performance. I believe the spectrum
of tag size we support is needed to give the system
integrator the

flexibility needed to met their requirements. [ Note: the

shortest tag size, 8 bytes, is only available with CCM].





2. Default Mandatory to Implement Configuration



We have four, one for CCM-126, one for CCM-256, one for
GCM-128 and

one for GCM-256. Yes I know, 4 != 1, but its close!



----------------+--------------------------------------------------








Kevin M. Igoe   | "We can't solve problems by using the same kind


[e-mail]  | of thinking we used when we created them."

|              - Albert Einstein -

----------------+--------------------------------------------------












-----Original Message-----

From: Stephen Farrell [mailto:[e-mail]]
Sent: Wednesday, October 29, 2014 8:28 AM To: The IESG Cc: 
[e-mail]; 
[e-mail] Subject:
Stephen Farrell's Discuss on
draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS)



Stephen Farrell has entered the following ballot position
for

draft-ietf-avtcore-srtp-aes-gcm-14: Discuss



When responding, please keep the subject line intact and
reply to all email addresses included in the To and CC lines.
(Feel free to cut this introductory paragraph, however.)





Please refer to 
http://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT
positions.





The document, along with other ballot positions, can be
found here:

http://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/










----------------------------------------------------------------------





DISCUSS:


----------------------------------------------------------------------












Before I move to a yes ballot, I want to chat about two things...




(1) There are perhaps too many choices being offered here to
be useful. It is very possible so much choice can harm
interop and hence security. Do we *need* the

256 bit key options now? Is CCM really *needed* here?

(Surprised the IEEE or h/w argument applies tbh) And why so
many auth. tag lengths? Who really *needs* all of those? The
DISCUSS point here is to validate that all of those options
really *need* (as opposed to can) be defined, which may have
been done already or may (and we have seen this) simply be a
case of defining everything in the hope that something gets
used. That can cause potential harm to interop. if different
coders pick up different options. And the "but the USG will
use all of these" is not IMO a sufficiently good argument for
defining all of them - we also have experience with PKI that
adding every option that the most complex deployments may
want is not the recipe for success (e.g. with enrolment
protocols).



(2) Unless discuss point (1) results in there being only one 
remaining option, (which I doubt:-), which of the options 
specified here are MTI, and if you argue that that needs to
be done elsewhere, then where will that be done? (We already
had a major extended discussion about SRTP MTI things in
general.) I would suggest that saying something like "128 bit
GCM with a tag length of 16 MUST be implemented by any
general purpose implementation of this specification" or
something similar.

 
 
 
 
  
  
  
Paging and Bottom Toolbar   Previous Item Next Item  
 
Connected to Microsoft Exchange