Re: [Cfrg] RFC 5116 update?

[John Mattsson <[e-mail]>]

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

On 2018-08-03, 00:12, "David McGrew (mcgrew)" <[e-mail]> wrote:

>Hi John,
>
>
>
>On 7/18/18, 9:32 AM, "John Mattsson" <[e-mail]> 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.  
>

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.

>I’m interested to hear what others think.
>
>Best
>
>David