Subject: [TLS] Fwd: New Version Notification for draft-zauner-tls-aes-ocb-04.txt

From: Aaron Zauner <[email-masked]>
Date: Wed, 6 Apr 2016 16:47:20 +0200

Hi,

I've uploaded a new version of the OCB draft a few days ago. Major changes:

- the nonce construction is now identical to the one from the chacha/poly draft to reduce risk of nonce misuse/reuse
- added a security considerations section on data limit under a single key (identical to GCM)
- IPR claims for TLS are now fully resolved as far as I can tell - the draft contains updated information on the issue

I'm happy to receive any feedback/critique on the draft if anyone is interested in reviewing.

BTW: Andy Polyakov has added AESNI optimized assembly for OCB to OpenSSL (https://github.com/openssl/openssl/commit/bd30091c9725bdad1c82bce10839f33ceaa5623b). C/B numbers are quite impressive, IMO.

Thanks for your consideration,
Aaron

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-zauner-tls-aes-ocb-04.txt
> Date: 4 April 2016 at 18:45:26 GMT+2
> To: "Aaron Zauner" <[email-masked]>
> Message-Id: <[email-masked]>
> 
> 
> A new version of I-D, draft-zauner-tls-aes-ocb-04.txt
> has been successfully submitted by Aaron Zauner and posted to the
> IETF repository.
> 
> Name:		draft-zauner-tls-aes-ocb
> Revision:	04
> Title:		AES-OCB (Offset Codebook Mode) Ciphersuites for Transport Layer Security (TLS)
> Document date:	2016-04-04
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-zauner-tls-aes-ocb-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/
> Htmlized:       https://tools.ietf.org/html/draft-zauner-tls-aes-ocb-04
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-zauner-tls-aes-ocb-04
> 
> Abstract:
>   This memo describes the use of the Advanced Encryption Standard (AES)
>   in the Offset Codebook Mode (OCB) of operation within Transport Layer
>   Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and
>   data origin authentication.  The AES-OCB algorithm is highly
>   parallelizable, provable secure and can be efficiently implemented in
>   software and hardware providing high performance.  Furthermore, use
>   of AES-OCB in TLS is exempt from former IPR claims by various
>   parties.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 6 Apr 2016 18:24:29 +0000

I seem to recall that Ted Krovetz some time ago submitted a draft (to
CFRG?) defining OCB: https://tools.ietf.org/html/draft-krovetz-ocb-04 .
Perhaps these two should be brought to sync, since the nonce construction
changes?
-- 
Regards,
Uri Blumenthal

On 4/6/16, 10:47 , "TLS on behalf of Aaron Zauner" <[email-masked]
on behalf of [email-masked]> wrote:

>- the nonce construction is now identical to the one from the chacha/poly
>draft to reduce risk of nonce misuse/reuse
>- IPR claims for TLS are now fully resolved as far as I can tell - the
>draft contains updated information on the issue
>
>BTW: Andy Polyakov has added AESNI optimized assembly for OCB to OpenSSL
>(https://github.com/openssl/openssl/commit/bd30091c9725bdad1c82bce10839f33
>ceaa5623b). C/B numbers are quite impressive, IMO.
>
>> URL:            
>>https://www.ietf.org/internet-drafts/draft-zauner-tls-aes-ocb-04.txt
>> Status:         
>>https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/
>> Diff:           
>>https://www.ietf.org/rfcdiff?url2=draft-zauner-tls-aes-ocb-04
>> 
>> Abstract:

---

From: Ted Krovetz <[email-masked]>
Date: Wed, 6 Apr 2016 11:54:28 -0700

An RFC for OCB was approved in 2014.

https://tools.ietf.org/html/rfc7253

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 6 Apr 2016 21:02:33 +0200

Hi Uri,

> Perhaps these two should be brought to sync, since the nonce construction

I'm not sure this is necessary as my draft is specific to the TLS
nonce construction and there's no need to update the primitive
itself. As far as I can tell this nonce construction doesn't conflict
with the RFC defining the primitive. I've switched to this new nonce
construction since it effectively prevents implementers from
re-using the same nonce as it would make implementations
non-interoperable, which I feel is a good thing. It's also similar
to how TLS 1.3 will form a nonce.

HTH,
Aaron

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 6 Apr 2016 19:10:22 +0000

On 4/6/16, 14:54 , "Ted Krovetz" <[email-masked]> wrote:

>An RFC for OCB was approved in 2014. https://tools.ietf.org/html/rfc7253

Excellent! I’m happy to hear that. ;)

The question remains: should these two definitions be brought to sync? I
seem to recall that we’ve had quite a bit of discussion about the nonce
for OCB…

Perhaps you want to take it with Aaron offline?

---

From: Peter Dettman <[email-masked]>
Date: Thu, 21 Apr 2016 13:07:20 +0700

draft-zauner-tls-aes-ocb-04 is now implemented in BouncyCastle TLS, and
I am looking for other implementations for interop testing.

Regards,
Pete Dettman