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

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Sep 2016 15:07:30 +1000

On 25 August 2016 at 08:08, Paul E. Jones <[email-masked]> wrote:
> If we take option (1), the right-alignment will result in the same numeric
> value as if no padding is introduced.  Thus the output would be precisely
> the same as option (3), since the salt is longer than the key_id.  Those
> options work, though I'll note that nowhere does RFC 3711 ever pad on the
> left.

Correct.  Option 1 and 3 are effectively the same.  I referred to
option 1 because in my interpretation that fits with the explanation
in 3711 better.

> Option (2) does padding in a way that is consistent with RFC 3711 and, as
> with option (1), padding at the outset addresses any issues had the salt
> been shorter than the key_id.

I don't agree that option 2 is consistent with 3711.  But, as fluffy
points out, we could be pragmatic about this and simply retcon as we
like to both RFCs (in an update) describing how this really happens in
the real world at the same time as fixing the ambiguities (in whatever
way we like).  That is, we could have a special exemption for 7714 and
a different answer for other protocols that might like to have smaller
key sizes (which is not a trend I see much of at this scale, but it
happens).

> Option (4) is actually a logical choice to make given the way RFC 3711 is
> defined.  What could have been stated in section 4.3.3 is that the IV is
> equal to ((x*2^8n), where n is 16 - length of x in octets).

The purpose of the left-shift/x*2^16 was to make room for the counter.
I have to assume that this is fixed, not variable.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 09 Sep 2016 05:49:15 +0000

Martin,

>option 1 because in my interpretation that fits with the explanation

Fit what explanation?  There's no logic I can see in taking a 12 octet 
value and padding two octets on the front to create a 14 octet value.

>key sizes (which is not a trend I see much of at this scale, but it

The consistency is that each time RFC 3711 wishes to expand a value, it 
is done via multiplying.  It's done with the IV to expand it from 14 
octets to 16 octets, it's done when forming packet index "i", and done 
when forming the IV for AES-CM when doing encryption.

If we have language in RFC 7714 to expand the master salt via s*2^16 
before that is used as input to the KDF (in a similar what that RFC 3711 
manipulates values), then we don't have to change any language in RFC 
3711 and we have a 16 octet quantity.  Nowhere in RFC 3711 is there 
explicit padding on the left.

>I have to assume that this is fixed, not variable.

It does create 0s in those positions, but this is a 128-bit value that 
monotonically increases modulo 128, so it wasn't strictly necessary to 
create room.  What was necessary was to form a 16 octet value, and 
that's the primary reason for the multiplication step.

Paul

---

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Sep 2016 17:51:19 +1000

On 9 September 2016 at 15:49, Paul E. Jones <[email-masked]> wrote:
> Fit what explanation?  There's no logic I can see in taking a 12 octet value
> and padding two octets on the front to create a 14 octet value.

See my previous mail.  3711 treats these as numbers rather than
sequences of octets when it talks about padding.

> The consistency is that each time RFC 3711 wishes to expand a value, it is
> done via multiplying.  It's done with the IV to expand it from 14 octets to
> 16 octets, it's done when forming packet index "i", and done when forming
> the IV for AES-CM when doing encryption.

I don't find that particularly compelling, but I see how you could get there.

> create room.  What was necessary was to form a 16 octet value, and that's
> the primary reason for the multiplication step.

I guess we're both still just speculating here, because the number of
ways to slice this are almost infinite.  For instance, why 14 octets
when 15 is better?