Subject: Re: [AVTCORE] AES-GCM SRTP (RFC 7714) KDF implementation

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 13 Jan 2017 14:21:34 +0000

So I have investigated this a bit more and here is what I have found. 100s, if not more, products all implemented it one way. There is an unverified rumor of 1 product that might have implemented it the other way but I can't seem to duplicate this. There is no rational plan of how one would do backwards interpretability with the existing stuff if we changed this from how it works now. One might do trial decryptions but from a practical point of view, this is awful to implement and from a theoretical point of view it weakens the security so that solution is worse in every way. There are no security differences between padding at front or back in this case. 

I feel very strongly we need to stick with the running code and not break all the existing stuff that has been successfully doing this for many years. Just document the what is in the code and lets move on. 

Martin, are you OK with staying with the running code?

> On Aug 25, 2016, at 8:38 AM, Cullen Jennings <[email-masked]> wrote:
> 
> So to be pragmatic about this ... how much running code will either choice A or B break? Do we need to make a new version this somehow if we are breaking deployed code so that running code knows which version it is dealing with and what to do?
> 
> 
>> On Aug 24, 2016, at 1:21 AM, Martin Thomson <[email-masked]> wrote:
>> 
>> On 24 August 2016 at 11:53, Paul E. Jones <[email-masked]> wrote:
>>> RFC 7714 specified a salt length of 12 octets.  And that's where the problem
>>> comes in.
>> 
>> If you (and 7714) were to use "master salt" consistently, the
>> confusion would have been easily avoided.
>> 
>> Either way, I agree that clarification is helpful.  My inclination is
>> to take option 1 here.  That matches S4.1.1 of 3711 where it defines
>> using right-alignment and it matches my understanding of the
>> mathematics used in 3711 (x is multiplied by 2^16, so presumably these
>> are big-endian numbers we are talking about rather than octet
>> sequences).
>> 
>> Option 2 seems like an error (assuming 7714 really does define
>> master_salt as being 12 octets), driven by examples rather than
>> normative language.  Options 3 and 4 (pad after XOR) don't fit with
>> the interpretation.
>> 
>> My guess is that 3711 doesn't define how big x is (that is, the output
>> of the XOR) because it assumes this to be a mere number.  It seems
>> like an oversight though.
>> 
>> So I guess that my conclusion is that no one is right.
>> 
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Jan 2017 16:50:50 +1300

> Martin, are you OK with staying with the running code?

Write it down clearly and I can live with any old rubbish.  It's the
internet we've got after all.

Just make sure that there are errata against the affected specs so
that we can avoid people making the problem worse by using the
interpretation that - at least to me - seems more obvious.