Subject: Re: [Cfrg] RFC 5116 update?

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Thu, 2 Aug 2018 22:12:17 +0000

Hi John,

On 7/18/18, 9:32 AM, "John Mattsson" <[email-masked]> wrote:

>The situation we have today is that recent IETF standards
>
>- COSE (RFC 8152),
>- Encrypted Content-Encoding for HTTP (RFC 8188),
>- TLS 1.3 (draft-ietf-tls-tls13),
>
>are not following the recommended nonce formation in Section 3.1 of RFC 5116. Instead they are constructing the nonce as
> 
>  NONCE = PRF( Shared secret, Public material ) XOR SEQ

Secure RTP (RFC 3711) does something similar.

>
>and keep the PRF( Shared secret, Public material ) part of the nonce secret. The nonce construction is analyzed in https://eprint.iacr.org/2016/564.pdf showing that it improves the resilience against (passive) mass surveillance. It should also improve the resilience against Grover's algorithm when the effective key length of the shared secret is larger than the AEAD key.

Randomized nonces certainly improve security.  We absolutely knew this during the standards process around counter-based modes; see for instance Section 4 of “Counter Mode Security: Analysis and Recommendations”, submission to NIST modes process, 2002, https://pdfs.semanticscholar.org/2c94/f83c8b30bf2da92bf711a73e30c843969199.pdf and the SRTP rationale in https://tools.ietf.org/html/rfc3711#section-7.2.  It is great to see the newer standards choosing security over other considerations like bandwidth and state-minimization, which caused some earlier standards to reject randomized nonces.  

>
>I think RFC 5116 should be updated to describe and recommend the nonce construction used in TLS 1.3. First, it would be good if RFC 5116 and current IETF protocols align. Secondly, I think the new nonce construction should be recommended to new protocols (IETF or non-IETF).
>
>Cheers,
>John
>

I think you are right, RFC 5116 should be recommending randomized nonces.  It also should be discussing nonce-misuse robustness and encouraging use of AES-GCM-SIV and AES-SIV and nonceless algorithms.  There are real-world implementations that get nonce generation wrong, with negative real-world security consequences, as described by Bock https://www.usenix.org/conference/woot16/workshop-program/presentation/bock.    

I made an earlier attempt to recommend better practices around nonce/iv generation in this draft https://tools.ietf.org/html/draft-mcgrew-iv-gen-03, back in 2013, which could be updated to reflect the three new RFCs that you mention.  It seems funny that a draft on nonce generation could be 26 pages long and yet be incomplete :-)    In any case, the text in this draft could be used to support a new RFC with improved nonce guidance.  

I’m interested to hear what others think.

Best

David

---

From: John Mattsson <[email-masked]>
Date: Wed, 29 Aug 2018 09:22:51 +0000

Thanks David,

I did not now about https://tools.ietf.org/html/draft-mcgrew-iv-gen-03, I think it contains a lot of good and very useful material that would have a value not only for IETF but also for other SDOs. I quite often see new specifications that refer to NIST 800-38D / RFC 5116 and therefore do not use an Unpredictable IV/Nonce with Randomizer/Salt.

(some more comments inline)

Cheers,
John

A good thing with a Randomizer (using the notation in Section 4.4 of draft-mcgrew-iv-gen-03) does not increase bandwidth and that the implementation has a trade-off between small increases in state or processing.

>I think you are right, RFC 5116 should be recommending randomized nonces.  It also should be discussing nonce-misuse robustness and encouraging use of AES-GCM-SIV and AES-SIV and nonceless algorithm…

Yes, I agree that 5116bis should describe nonce-less algorithms and encourage use of nonce-misuse-resistant algorithms.

>I made an earlier attempt to recommend better practices around nonce/iv generation in this draft https://tools.ietf.org/html/draft-mcgrew-iv-gen-03, back in 2013, which could be updated to reflect t…

I think the information in draft-mcgrew-iv-gen is very good and useful. It should be published somehow. As draft-mcgrew-iv-gen is covering IV construction also not non-AEAD algorithms it might make sense to publish it separately and let RFC5116bis reference it. Alternatively, the information from draft-mcgrew-iv-gen could be included in RFC5116bis.

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 30 Aug 2018 12:06:19 -0700

On 29 Aug 2018, at 2:22, John Mattsson wrote:

> Thanks David,
>
> I did not now about 
> https://tools.ietf.org/html/draft-mcgrew-iv-gen-03, I think it 
> contains a lot of good and very useful material that would have a 
> value not only for IETF but also for other SDOs. I quite often see new 
> specifications that refer to NIST 800-38D / RFC 5116 and therefore do 
> not use an Unpredictable IV/Nonce with Randomizer/Salt.
>
>>> are not following the recommended nonce formation in Section 3.1 of 
>>> RFC 5116. Instead they are constructing the nonce as
>>>
>>> and keep the PRF( Shared secret, Public material ) part of the nonce 
>>> secret. The nonce construction is analyzed in 
>>> https://eprint.iacr.org/2016/564.pdf showing that it improves the 
>>> resilience against (passive) mass surveillance. It should also 
>>> improve the resilience against Grover's algorithm when the effective 
>>> key length of the shared secret is larger than the AEAD key.
>>
> Randomized nonces certainly improve security.  We absolutely knew this 
> during the standards process around counter-based modes; see for 
> instance Section 4 of “Counter Mode Security: Analysis and 
> Recommendations”, submission to NIST modes process, 2002, 
> https://pdfs.semanticscholar.org/2c94/f83c8b30bf2da92bf711a73e30c843969199.pdf 
> and the SRTP rationale in 
> https://tools.ietf.org/html/rfc3711#section-7.2.  It is great to see 
> the newer standards choosing security over other considerations like 
> bandwidth and state-minimization, which caused some earlier standards 
> to reject randomized nonces.
>>
>
> A good thing with a Randomizer (using the notation in Section 4.4 of 
> draft-mcgrew-iv-gen-03) does not increase bandwidth and that the 
> implementation has a trade-off between small increases in state or 
> processing.
>
>>>
>>> I think RFC 5116 should be updated to describe and recommend the 
>>> nonce construction used in TLS 1.3. First, it would be good if RFC 
>>> 5116 and current IETF protocols align. Secondly, I think the new 
>>> nonce construction should be recommended to new protocols (IETF or 
>>> non-IETF).
>>>
>>> Cheers,
>>> John
>>>
>>
>> I think you are right, RFC 5116 should be recommending randomized 
>> nonces.  It also should be discussing nonce-misuse robustness and 
>> encouraging use of AES-GCM-SIV and AES-SIV and nonceless algorithms.  
>> There are real-world implementations that get nonce generation wrong, 
>> with negative real-world security consequences, as described by Bock 
>> https://www.usenix.org/conference/woot16/workshop-program/presentation/bock.
>>
>
> Yes, I agree that 5116bis should describe nonce-less algorithms and 
> encourage use of nonce-misuse-resistant algorithms.
>
>> I made an earlier attempt to recommend better practices around 
>> nonce/iv generation in this draft 
>> https://tools.ietf.org/html/draft-mcgrew-iv-gen-03, back in 2013, 
>> which could be updated to reflect the three new RFCs that you 
>> mention.  It seems funny that a draft on nonce generation could be 26 
>> pages long and yet be incomplete :-)    In any case, the text in this 
>> draft could be used to support a new RFC with improved nonce 
>> guidance.
>>
>
> I think the information in draft-mcgrew-iv-gen is very good and 
> useful. It should be published somehow. As draft-mcgrew-iv-gen is 
> covering IV construction also not non-AEAD algorithms it might make 
> sense to publish it separately and let RFC5116bis reference it. 
> Alternatively, the information from draft-mcgrew-iv-gen could be 
> included in RFC5116bis.

+1

Given the scope of the document, I would like to see draft-mcgrew-iv-gen 
move forward, and referencing it in RFC5116bis seems best. I’m willing 
to help both efforts.

Best,
Chris

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Aug 2018 10:43:44 +1000

> move forward, and referencing it in RFC5116bis seems best. I’m willing

The work is certainly valuable, but the framing seems a little off.
In the settings you are concerned with, the primary characteristic we
are concerned with is that the IV is unique.  That we use a
deterministic process to produce this value [1], isn't the main point
and it could result in some misconceptions about what is going on.

I'd like to see this include some discussion of nonce-misuse-resistant
primitives as well, noting how they fit into the picture.

[1] A counter, a counter mixed with some other value (concatenation,
XOR, and add have all been used), a function over the plaintext or
other inputs, a counter and PRP, ..., honestly I don't know why anyone
would think a mere 26 pages is enough!

---

From: Christopher Wood <[email-masked]>
Date: Thu, 30 Aug 2018 18:35:33 -0700

> and it could result in some misconceptions about what is going on.

Yes, good point. It should be clear that techniques such as those
listed in [1] exist to construct (for these settings) unique IVs.

> primitives as well, noting how they fit into the picture.

Agreed.

> would think a mere 26 pages is enough!

:-)