Subject: [TLS] Inclusion of OCB mode in TLS 1.3

From: Aaron Zauner <[email-masked]>
Date: Tue, 13 Jan 2015 18:04:26 +0100

Hi TLS-WG,

Over the last couple of days I've again looked into OCB, read the
original paper as well as quite some literature on it, patents, CFRG
discussion et cetera.

OCB looks like an elegant and parallel mode for inclusion in TLS.
I've searched through recent TLS-WG discussion, OCB has been
mentioned in passing as has EAX(2). When first looking into that my
main concerns were:

   * IPR/patents: the authors have granted access to OSI licensed
     software as well as to commercial (non military!) software for
     all use [0] [1].

   * IETF applicability: an informational RFC has been written by
     the original author of OCB mode, reviewed and accepted by CFRG
     and published by IESG in May 2014 [RFC7253].

   * Software implementations: OCB mode is available in various
     cryptographic libraries:

      - OpenSSL's 1.0.2 branch

(https://github.com/openssl/openssl/blob/0c1bd7f03fcd1cc8256f89f4962d91b78432c74a/crypto/modes/ocb128.c)

      - Bouncy Castle
        (https://www.bouncycastle.org/specifications.html)

      - Botan

(https://github.com/randombit/botan/tree/74522169a907715d4d41b3680f20b6f866733de7/src/lib/modes/aead/ocb)

      - Soon; dynamic languages linking to these libraries.

      - I might have left out a few, where I couldn't find a
        clear indication that they intend to support OCB mode.

From looking at [RFC7253] it would make sense to have;
`AEAD_AES_128_OCB_TAGLEN64` and `AEAD_AES_256_OCB_TAGLEN128` in TL3
1.3 ciphersuites.

Now I'm a bit clueless as to how new AEAD modes are supposed to be
added to TLS 1.3. In the past there have been various documents
extending TLS ciphersuites by a certain block cipher/AEAD mode:
[RFC5288] [RFC6367] [RFC6655] [RFC5528] [RFC6209]. There is a
general document for an interface for AEAD modes [RFC5116] which the
authors have used for their informational RFC [RFC7253]. I'd like to
ask for a bit of guidance how this can be done more efficiently for
all ciphers that will end up in TLS 1.3. Having a seperate RFC for
every cipher and thus ciphersuite seems a bit confusing. Is this the
intended approach still?

I'd be willing to author such a document or make the necessary
changes to the TLS 1.3 draft in order to get OCB mode into TLS 1.3.
Currently we're limited to GCM (with known issues on mobile
plattforms) and CCM (CBC-MAC, which is one of the reasons the OCB
authors started work on this mode, because it's more elegant and
efficient).

Recent developments regarding OCB mode are documented here:
http://web.cs.ucdavis.edu/~rogaway/ocb/news/

All and any input appreciated.

Thanks,
Aaron

[0] https://www.ietf.org/mail-archive/web/cfrg/current/msg03301.html
[1] http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:phil

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Jan 2015 09:26:24 -0800

On 13 January 2015 at 09:04, Aaron Zauner <[email-masked]> wrote:
> added to TLS 1.3.

In this case, I would suggest writing an Internet Draft describing how
the cipher suite is identified and how it operates.  That would be a
relatively short document.

Unless there are specific reasons not to, a new AEAD cipher should be
defined for TLS 1.2 as well.  One reason (that doesn't apply to OCB)
is that it might require non-deterministic padding, for which there is
a bug in the TLS 1.2 AEAD construction (see
https://github.com/tlswg/tls13-spec/issues/47).

There are, of course, reasons why people would not want to accept a
proposal like that.  More cipher suites isn't strictly a good thing.
Of course, if OCB is demonstrably better in some fashion (speed,
security, whatever it happens to be), then that makes the case easier.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Jan 2015 12:28:21 -0500

> Of course, if OCB is demonstrably better in some fashion (speed, security,
> whatever it happens to be), then that makes the case easier.

That "no military use" being particularly problematic.  Does anyone know if the IETF has other IPR grants with similar field-of-use limitations?

	/r$

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 13 Jan 2015 18:32:55 +0100

> That "no military use" being particularly problematic.  Does anyone know if the IETF has other IPR grants with similar field-of-use limitations?
I agree (actually, personally; I do not care). But it seems to have made
through CFRG/IESG review and was accepted (see rogaways email regarding
IPR issues). Can someone with more knowledge about handling IPR issues
like this very specific one comment on this?

Thanks,
Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 13 Jan 2015 18:43:44 +0100

> https://github.com/tlswg/tls13-spec/issues/47).

Thanks for this piece of information! So that would be an ID to the
extent of RFC5288 or RFC6655.

> security, whatever it happens to be), then that makes the case easier.

Generally I would agree, but I think for now OCB mode would be a very
good addition to AEAD in TLS. Let's see what the CAESAR competition
brings us in 2017,..

Aaron

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Jan 2015 12:45:22 -0500

I do not mind OCB being specified for _optional_ use with TLS, but there are unencumbered alternatives, and one of those alternatives should be the mandatory to implement algorithm.

Russ

On Jan 13, 2015, at 12:04 PM, Aaron Zauner wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 13 Jan 2015 18:51:15 +0100

> I do not mind OCB being specified for _optional_ use with TLS, but there are unencumbered alternatives, and one of those alternatives should be the mandatory to implement algorithm.

I'm not intimately familiar with EAX(2) but it seems to be a viable
option. I'm currently focused on OCB and the feedback of TLS-WG. If
nobody want's to see it in TLS, I'm not going to write an ID.

Aaron

---

From: Watson Ladd <[email-masked]>
Date: Tue, 13 Jan 2015 09:54:49 -0800

> nobody want's to see it in TLS, I'm not going to write an ID.

The advantage of OCB is its high efficiency and easy implementation on
a wide range of platforms. I agree it shouldn't be mandatory, but
plenty of people will want to use it, particularly on embedded
platforms.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Matt Caswell <[email-masked]>
Date: Tue, 13 Jan 2015 18:09:06 +0000

> (https://github.com/openssl/openssl/blob/0c1bd7f03fcd1cc8256f89f4962d91b78432c74a/crypto/modes/ocb128.c)

A
slight correction. OCB is not in the OpenSSL 1.0.2 branch. It is in
the master branch (which means its scheduled for 1.1.0).

Matt

---

From: Matt Caswell <[email-masked]>
Date: Tue, 13 Jan 2015 18:13:33 +0000

> That "no military use" being particularly problematic.  Does anyone know if the IETF has other IPR grants with similar field-of-use limitations?

For the record, the "no military use" clause only applies to the generic
OSI licence. It was that restriction that prevented OCB's inclusion in
OpenSSL for some while. The OpenSSL implementation uses a different licence:
https://www.openssl.org/docs/misc/OCB-patent-grant-OpenSSL.pdf

This is not encumbered by the no military use restriction.

Matt

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Jan 2015 13:18:55 -0500

> This is not encumbered by the no military use restriction.

Arguably worse from the IETF viewpoint because it would be constraining to a particular field of use OR to a particular implementation.  That last half ... no way.

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 13 Jan 2015 19:25:00 +0100

> Arguably worse from the IETF viewpoint because it would be constraining to a particular field of use OR to a particular implementation.  That last half ... no way.

As far as I understand that means: It's free to use for everone except
commercial military-use implementations. I agree that's not optimal for
an IETF standard, but as OPTIONAL, this should work. *And* could be used
in FOSS software and/or embedded systems, where it makes most sense.

Aaron

---

From: Matt Caswell <[email-masked]>
Date: Tue, 13 Jan 2015 18:28:53 +0000

> Arguably worse from the IETF viewpoint because it would be constraining to a particular field of use OR to a particular implementation.  That last half ... no way.

If that was seen as a blocker then its probably worth starting a
conversation with Phil Rogaway. He was very amenable to dealing with the
OpenSSL issue.

Matt

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 13 Jan 2015 19:48:54 +0100

Hi,

Paul Lambert wrote:
> Yes, OCB is a very nice AEAD.
> 
> No - the IETF IPR database statement does reflect the claims in [1]
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-irtf-cfrg-oc
> b 
> 
> The problem with OCB, when first introduced as an option for
> 802.11i was that there were multiple claimed owners of the IPR.
> 
> This still seems to be the case.  Looking at the IETF IPR disclosures:
> 	#6,973,187 - Gligor & Donescu (VDG Inc)
> 	#6,963,976  #7,093,126 - Jutla (IBM)
> 	#7,046,802 #7,200,227 #7,949,129 #8321675 - Rogaway

Thanks for pointing this out.

FYI: CFRG members made some statements regarding different IPR (and
performance) issues in discussions [0] [1] [2]. Rogaway is pretty clear
on his own patents in [3].

This did not seem to stop adoption.

> This should not stop inclusion of OCB as an optional mode in TLS,
> but OCB is not clearly Œfree¹.

Sure. I agree. I'd still be nice to have it in there though.

Aaron

[0] https://www.ietf.org/mail-archive/web/cfrg/current/msg03300.html
[1] https://www.ietf.org/mail-archive/web/cfrg/current/msg03277.html
[2] https://www.ietf.org/mail-archive/web/cfrg/current/msg02989.html
[3] https://www.ietf.org/mail-archive/web/cfrg/current/msg03301.html

---

From: Paul Lambert <[email-masked]>
Date: Tue, 13 Jan 2015 10:25:16 -0800

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Jan 2015 21:34:19 +0000

<no-hats>

> This should not stop inclusion of OCB as an optional mode in TLS,

I don't get why additional options are at all attractive. In
fact, I think they're ugly.

TLS has about 327 ciphersuites. That's just stupid. (I'm not
saying any person is stupid there btw, but we have gotten
ourselves into a stupid place.)

If we have a really better thing, they why not make it MTI? If
we do not have something sufficiently better then I'd argue to
exclude as much as possible, and certainly against adding
anything that is just nice to have.

I'd even like to make almost all current ciphersuites a MUST NOT
(or start a new registry) for TLS1.3 and to not add any new
ciphersuites at all, and just stick with two MTI ciphersuites
that are as genetically different as possible and cover as many
implementations (h/w AES or not) as possible.

So my suggestion is to reduce the ciphersuite field to be
2 bits wide in TLS 1.3, with 00 being default, 01 backup, 02
being "proprietary" and 03 reserved. If either 00 or 01 needs
to be changed then I'd say rev the TLS version. (I don't care
if we did s/default/has-AES-hw/ and s/backup/just-sw-crypto/
that'd also be fine.)

And yes, I realise that's not likely to get traction, but
turning 327 into 427 is even dumber when reality shows that
only a few of 'em are used or needed.

<no-hats>

With a random hat: the OCB RFC is an IRTF informational document
and had CFRG consensus for publication. Using that in a standards
track spec would require TLS WG consensus, and then IETF consensus.
So there's no magic, just the usual IPR processing that each
participant has to do for themselves. I'd be pretty confident in
a bet that the odd encumbrance of OCB will be a hard barrier to
overcome, but who knows.

Cheers,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 14 Jan 2015 00:25:38 +0000

> fact, I think they're ugly.

Yes, except that OCB might well have been the most attractive AEAD
mode to implement, were it not for IPR and the history of how we
got here.  On a purely technical basis it appears superior to GCM.

> anything that is just nice to have.

It would be nice to get there some day.  However we're still actively
discovering what works:

	* Which EC curves and signature schemes to use

	* Which modes to use

	* Which stream ciphers to use (have we settled on ChaCha20 yet?)

	* Which block ciphers to use (must TLS support CAMELLIA? SEED?)

	* Which hash functions to use (though SHA-2 is holding up well)

Plus of course TLS is used in a rather diverse set of applications
whose needs vary.

> So my suggestion is to reduce the cipher suite field to be

This would then require per-application TLS "profiles", with
per-application definitions of the two ciphersuites in question.
I don't think that'll work just yet.

We might be able to get away with approximately two choices per
degree of freedom:

    * Two public key systems (RSA and ECDSA and/or EdDSA, drop DSA?).

    * A couple of block ciphers (AES and CAMELLIA, drop SEED, IDEA, RC2, ...?).

    * Two key lengths 128 and 256.

    * One or two stream ciphers (ChaCha20 and ???).

    * A couple of AEAD variants (GCM, Poly1305, OCB?)

    ...

Which should still be a smaller set of possible outcomes that the
current ~327, but I think we are sadly far from having just two be
realistic.

-- 
	Viktor.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 14 Jan 2015 00:32:37 +0000

Good points!

Also, do we acknowledge that there will be specific applications that need
specific cipher suites that are not included in those few selected for
universal use (i.e. a couple of AEAD modes, a couple of block ciphers,
etc)?

For example, what if Russia insists on using Kuznetchik? Surely you don’t
expect everybody to implement it, but surely you don’t expect them to say
“IETF did not bless Grasshopper for TLS, so we’ll switch to AES-based
suites, or use ChaCha20”?

How are we planning to handle such “special” needs?
-- 
Regards,
Uri Blumenthal                               Voice: (781) 981-1638

---

From: Brian Smith <[email-masked]>
Date: Tue, 13 Jan 2015 16:38:17 -0800

Aaron Zauner <[email-masked]> wrote:
> Having a seperate RFC for

I agree that it ideally we wouldn't insist on a separate RFC for every
cipher suite. On the other hand, because of IPR concerns and other
non-technical factors, I think it is better to specify these cipher
suites in a separate RFC. That way, there'd be no risk of IPR concerns
clouding the IPR status of TLS 1.3 itself and/or delaying its
publication.

Cheers,
Brian

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 14 Jan 2015 01:01:26 +0000

On 1/13/15, Salz, Rich <[email-masked]> wrote:
>> security,
> That "no military use" being particularly problematic.  Does anyone know if
> the IETF has other IPR grants with similar field-of-use limitations?
>

I don't see it as problematic at all. It is his right and also his
responsibility. I think it is fantastic that Phil Rogaway is aware of
his power and uses it. It sounds like he willing to talk about it too.
This discussion even comes up because of that reasonable use of power.

The concern trolling and endorsement of the military is much more
problematic, frankly. Especially since we know that they run people as
part of the BULLRUN[0] programs to influence standards bodies - such
as the IETF specifically!

Hopefully OCB will be included in TLS 1.3 without a separate RFC. It
seems like Phil's page has specific licenses that are very
reasonable[1]:

"That said, I have freely licensed any IP I own over a very large
space: there is one license grant for open-source software; one for
non-military software; and a third done just for OpenSSL.

All the best,
Jacob

[0] https://en.wikipedia.org/wiki/Bullrun_(decryption_program)
[1] http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:phil

---

From: Joachim Strömbergson <[email-masked]>
Date: Wed, 14 Jan 2015 07:54:07 +0100

Aloha!

> On 14 Jan 2015, at 02:01, Jacob Appelbaum <[email-masked]> wrote:
> 

For us doing open source HW designs, having licenses that specifically specifies usage rights for open source _software_ it becomes problematic. Please just state "open source" if possible.

Phil's license is an example of such a problem. I've written to him asking if it would be possible to also allow open HW implementations of OCB. Unfortunately I've yet to receive a response.

Yours
JoachimS

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 14 Jan 2015 15:46:50 +0100

Hi Stephen,

> ourselves into a stupid place.)

Yup. Having different naming schemes for different
libraries/implementations beyond that makes it almost impossible to give
good recommendations to end-users (admins, management) as we've noticed
in the bettercrypto.org project.

> only a few of 'em are used or needed.

Just as a suggestion, how about a document that does only include
forward-secret cipher-suites that are valid for TLS 1.3? That would
drastically remove the number of OCB ciphersuites that I would have to
add in case of TLS 1.2.

One issue though: as far as I can tell (from the recent RWC presentation
by EKR) there are still going to be three block ciphers in TLS 1.3: AES,
CAMELLIA, ARIA. One could also only define ciphersuites for AES. The
original paper only talks about the merits of OCB mode with AES - so
this would make sense. Since of the other ciphers are -- to some extent
-- based on AES, OCB mode would work perfectly fine with them, but then
again; who really uses them? I certainly agree that ciphersuite
pollution is not the best way to go. But having three different AEAD
block modes to choose from is.

Is this a reasonable proposal?

As for Jake's comment: Personally I fully agree with that, but can see
why the military exception would make it hard for IETF to have this mode
as mandatory to implement. So it'd probably end up as optional. Given
that support for OCB is already present in (some) implementations; this
would, again, make sense.

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 14 Jan 2015 16:26:15 +0100

Hi *,

> drastically remove the number of OCB ciphersuites that I would have to

Going through the ChaCha20/Poly1305 ID, it suggest something very
similar, only adding three ciphersuites:
http://tools.ietf.org/id/draft-agl-tls-chacha20poly1305-04.txt (S. 6).

Aaron

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 14 Jan 2015 10:30:03 -0500

TLS 1.3 is already AEAD and PFS only, since draft-02:
	Removed support for static RSA and DH key exchange.
	Removed support for non-AEAD ciphers

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 14 Jan 2015 16:46:35 +0100

> 	Removed support for non-AEAD ciphers
Yes, I know. Exactly.

One previous suggestion in this thread was to add ciphersuites down to
TLS 1.2, which would result in an enormous amount of ciphersuites as
Stephen Farrell pointed out earlier. Hence the title of this thread and
my asking if a proposal that only adds TLS 1.3 compatible ciphersuites
would be acceptable by the WG.

Aaron

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 14 Jan 2015 16:51:27 +0100

> http://tools.ietf.org/id/draft-agl-tls-chacha20poly1305-04.txt (S. 6).

This is not the case in the latest draft. Defining only 3 ciphersuites
means that PSK will not take advantage of the OCB mode. Is there a
reason for that?

regards,
Nikos

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 14 Jan 2015 17:11:00 +0100

Hi Nikos,

> means that PSK will not take advantage of the OCB mode. Is there a

No. If PSK is still going to be supported in TLS 1.3 then I'll have to
add that as well. This was the newest draft on ChaCha20/Poly1305 I could
find on the IETF website. Still not that bad in comparison to adding all
the cipher-suites that conforming with TLS 1.2 would mean.

Aaron

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 14 Jan 2015 17:43:54 +0100

> the cipher-suites that conforming with TLS 1.2 would mean.

 Hi,
I don't see why OCB has to be tied to TLS 1.3. The last time such move
was made with having GCM/AEAD restricted to TLS 1.2, it proved quite
wrong (in the sense that not doing it would have avoided the majority of
the problems we saw the last years). TLS 1.3 is a draft document to be
deployed in 2-3 years after published (in the best case scenario). There
is no reason the existing implementations cannot take advantage of OCB,
if ever defined. 

regards,
Nikos

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 14 Jan 2015 17:51:55 +0100

> is no reason the existing implementations cannot take advantage of OCB,
I'm trying to find a compromise between having to pollute the TLS
ciphersuite registry with tons of ciphersuites (as has been pointed out
to me is not desirable) and OCB being deployable in the real world for
implementors that would like to use it (and are allowed to w.r.t. it's
licensing).

If the majority is for a) dropping the idea b) having OCB in >= TLS 1.2,
and thus tons of ciphersuites or c) for TLS 1.3 applicable ciphersuites
only - I'll draft it that way.

Having this discussion beforehand will also save time on editing the
draft all the time, in case on is to be written.

I'm open for any suggestions and some consensus on the topic would be nice.

Aaron

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Jan 2015 09:02:16 -0800

On Wed, Jan 14, 2015 at 6:46 AM, Aaron Zauner <[email-masked]> wrote:

> CAMELLIA, ARIA.

To be clear, this is just a statement of fact. I.e., TLS 1.3 can only be
used
with AEAD and these are the AEAD ciphers that are presently defined.
The WG could adopt more AEAD ciphers or conversely, remove ones that
currently exist.

Speaking only for myself, it seems like AES-GCM is the leading candidate
for the MTI for TLS 1.3, based on the fact that it's the most common
AEAD algorithm with 1.2.

-Ekr

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 16 Jan 2015 16:58:36 +0100

Hi,

I came up with the following list of cipher-suites applicable to >= TLS 1.2:

(EC)DHE:
TLS_DHE_RSA_WITH_AES_128_OCB	
TLS_DHE_RSA_WITH_AES_256_OCB
TLS_ECDHE_RSA_WITH_AES_128_OCB
TLS_ECDHE_RSA_WITH_AES_256_OCB
TLS_ECDHE_ECDSA_WITH_AES_128_OCB
TLS_ECDHE_ECDSA_WITH_AES_256_OCB

PSK:
TLS_DHE_PSK_WITH_AES_128_OCB
TLS_DHE_PSK_WITH_AES_256_OCB	
TLS_ECDHE_PSK_WITH_AES_128_OCB
TLS_ECDHE_PSK_WITH_AES_256_OCB

As for the nonce, would it make sense to use a 128bit nonce for both
AES128 and AES256 instead of 64/128 (see:
https://www.imperialviolet.org/2014/05/25/strengthmatching.html)?

What about SRP? Gone in 1.3? I tend to like SRP although it's rarely used.

Any objections, additions and/or comments?

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 16 Jan 2015 17:47:07 +0100

> https://www.imperialviolet.org/2014/05/25/strengthmatching.html)?
Sorry. Clarification; this refers to the tag length (TAGLEN) from
RFC7253, not the nonce as used in the TLS context.

Aaron

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sat, 17 Jan 2015 10:54:34 +0100

> TLS_ECDHE_PSK_WITH_AES_256_OCB
I think it would make sense to also include pure PSK (no DH) suite for very
constrained devices that can't afford the asymetric crypto.

Manuel.

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 17 Jan 2015 16:11:07 +0100

> constrained devices that can't afford the asymetric crypto.

Makes sense. So your suggestion is to swap or add these
ciphersuites? I have no real-world data on the usage of TLS with
pre-shared keys, nor it's deployment. I can only guess, would be
interesting to hear the opinion of embedded development people on
that subject.

Aaron

---

From: Alex Elsayed <[email-masked]>
Date: Sun, 18 Jan 2015 04:06:23 -0800

>      software as well as to commercial (non military!) software for
<snip>

Note that while the authors have licensed their patents, IIRC there are 
still concerns over whether the Gligor & Donescu or Jutla patents [1] apply.

In addition, I'd like to call the attention of the group to the CAESAR AEAD 
competition [2], in which there are multiple entrants (and Rogaway &c has 
submitted a new mode "AEZ" in addition to OCB). There is a mailing list [3] 
for discussion and a wiki [4] which has collected the entrants, similar to 
the SHA-3 Zoo.

One thing in particular that may be worth thinking about is that several of 
the modes proposed are nonce-misuse resistant, akin to SIV.

[1] 6,963,976, 6,973,187, 7,093,126, and 8,107,620.
[2] http://competitions.cr.yp.to/caesar.html
[3] https://groups.google.com/forum/#!forum/crypto-competitions
[4] http://aezoo.compute.dtu.dk/

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 19 Jan 2015 09:10:57 +0100

> constrained devices that can't afford the asymetric crypto.

Plain PSK can also be used to establish an additional channel in an
existing TLS connection (which may already already be under PFS).

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 19 Jan 2015 10:03:09 +0100

> interesting to hear the opinion of embedded development people on

I don't believe you can second guess here. There can be many valid
use-cases unknown to anyone in the WG, or IETF, as PSK is often used in
protocols which are non-standardized or standardized outside IETF.

regards,
Nikos

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 19 Jan 2015 15:03:30 +0100

> for discussion and a wiki [4] which has collected the entrants, similar to 

I've already noted CAESAR in this thread. The problem being: the
competition ends in 2017 as far as I know. Until then we're stuck with
what we have right now (plus ChaCha20/Poly1305 probably).

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 19 Jan 2015 15:06:54 +0100

> protocols which are non-standardized or standardized outside IETF.

I'm not trying to second guess anybody/anything. I'd like to have some
common ground. If I take the lead from RFC6655 (AES-CCM) that'd be:

CipherSuite TLS_PSK_WITH_AES_128_OCB
CipherSuite TLS_PSK_WITH_AES_256_OCB
CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB
CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB

>>>> TLS_ECDHE_PSK_WITH_AES_256_OCB

Does this make sense for you?

Thanks,
Aaron

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 19 Jan 2015 15:12:04 +0100

> Does this make sense for you?

Yes that looks reasonable.

regards,
Nikos

---

From: Jack Lloyd <[email-masked]>
Date: Tue, 20 Jan 2015 12:09:54 -0500

> https://www.imperialviolet.org/2014/05/25/strengthmatching.html)?

OCB mode as defined in RFC 7253 supports nonces of at most 120 bits.

When used in TLS both GCM and CCM use 96 bit nonces, 32 from key
exchange and 64 explicit in the message. Given the 2^64 message limit
(and that any sensible implementation just uses the sequence number
for the 64 nonce bits included in each message) I don't see why OCB
should require anything different. A 128 bit nonce isn't increasing
the security level when it is already 100% guaranteed that the nonce
will never repeat using just 96.

Another option would be to avoid explicit nonces entirely and
following ChaCha20 define the nonce to always be exactly the sequence
number in network order. This value is known to be unique for protocol
reasons, and it avoids the wire bytes taken for any explicit value.

Cheers,
  Jack

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 20 Jan 2015 19:02:51 +0100

> reasons, and it avoids the wire bytes taken for any explicit value.
Yes, thanks! I figured that out on my own a couple of days ago.
Unfortunately the ID I submitted still has the TAGLEN128 constructs in
it (I forgot to edit this part). So there's probably going to be a -01.
Let's see if my submission gets accepted.

Thanks for your feedback,
Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 20 Jan 2015 20:18:21 +0100

Hi TLS-WG,

The Internet Draft can be found over here:
https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/

Further discussion very welcome.

One of the things I have in mind, right now there're two PSK
ciphersuites defined (that I defined because they're in CCM and GCM
as well) that do not make much sense in my opinion. These are PSK
with DHE. For embedded devices the use of ECDHE is for sure more
suitable. So removing those would be an option. Right now this ID
would add twelve (12) new ciphersuites to the TLS ciphersuite
registry, if we /can/ get rid of these two we're down to ten (10).

As always; any input appreciated,
Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 20 Jan 2015 20:34:13 +0100

> https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/

PS: In TLS-WG fashion I've put the draft on GitHub and Travis-CI for
issues and Pull Requests (thanks to Martin Thompson for his great
template!). In accordance to IETF contribution guidelines all comments 
must also be made to this very mailing list.

https://github.com/azet/draft-zauner-tls-aes-ocb

Aaron

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Jan 2015 14:17:25 -0800

> https://github.com/azet/draft-zauner-tls-aes-ocb

LGTM, providing you get interest in shipping it.

Is the following premise entirely correct?

Because
   TLS has no way for the client to indicate that it supports TLS 1.2
   but not earlier, a non-compliant server might potentially negotiate
   TLS 1.1 or earlier and select one of the cipher suites in this
   document.

Maybe instead:

A client MUST treat the selection of these cipher suites in
combination with a version of TLS that does not support AEAD (i.e.,
TLS 1.1 or earlier) as an error and generate a fatal
'illegal_parameter' alert.

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 20 Jan 2015 23:53:37 +0100

> 'illegal_parameter' alert.

Makes sense. The quoted text was copied verbatim by myself from
the GCM/CCM RFCs. I'm happy to include your suggestion as a
replacement. Maybe change the last sentence to:
"..and generate a fatal 'illegal_parameter' TLS alert response"?

Aaron

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Jan 2015 15:35:25 -0800

> "..and generate a fatal 'illegal_parameter' TLS alert response"?

Sure.  Though s/response//; it's not a response in the classic sense,
just a message.

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 21 Jan 2015 01:47:05 +0100

> Sure.  Though s/response//; it's not a response in the classic sense,

Tracked & Changed as suggested:
https://github.com/azet/draft-zauner-tls-aes-ocb/issues/1
https://github.com/azet/draft-zauner-tls-aes-ocb/commit/8c93b4c4d799675468f2b460dbb8fbc53e88fe6c

Thanks,
Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 21 Jan 2015 16:17:58 +0100

Hi,

Any comments on the idea of removing the following two ciphersuites from
the draft?

     CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB = {TBD9, TBD9}
     CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB = {TBD10, TBD10}

I don't see how these would be relevant to embedded devices.

Aaron

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Jan 2015 08:15:45 -0800

If we generally think DHE_PSK is a good idea, is there a specific reason why
it wouldn't be a good idea for OCB?

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 21 Jan 2015 16:21:38 +0000

> Right now this ID would add twelve (12) new ciphersuites to
> the TLS ciphersuite registry, if we /can/ get rid of these two we're down to
> ten (10).

Gaak.

What does OCB bring to the table that justifies such a huge increase (10%) in the number of ciphers.

We need a cipher cage match.  They call go in, and only a couple come out.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 21 Jan 2015 08:25:36 -0800

> What does OCB bring to the table that justifies such a huge increase (10%) in the number of ciphers.

Side-channel resistance and performance on hardware with AES but no
carryless multiplier.

> We need a cipher cage match.  They call go in, and only a couple come out.

If you don't need to support them all, what's the cost (assuming they
are all secure)?

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 21 Jan 2015 16:28:07 +0000

> If you don't need to support them all, what's the cost (assuming they are all
> secure)?

That's a pretty weighty assumption.  And how do you decide which ones you have to support, which are MTI, etc?  How do you advise customers to use OCB over their favorite national cipher, like GOST or SEED?  Or Camellia?

---

From: Nico Williams <[email-masked]>
Date: Wed, 21 Jan 2015 10:40:42 -0600

On Wed, Jan 21, 2015 at 04:28:07PM +0000, Salz, Rich wrote:
> > If you don't need to support them all, what's the cost (assuming
> > they are all secure)?
> 
> That's a pretty weighty assumption.  And how do you decide which ones
> you have to support, which are MTI, etc?  How do you advise customers

None would be required to implement.

> to use OCB over their favorite national cipher, like GOST or SEED?  Or
> Camellia?

We wouldn't.  Customers who have to give preference to national
ciphers... would, and presumably the legislation and regulations they
are subject to would say something about cipher modes (or, if not, then
what modes they prefer seems irrelevant since it's just a preference and
the negotiation should just work).

Nico
--

---

From: Henrik Grubbström <[email-masked]>
Date: Wed, 21 Jan 2015 17:41:40 +0100

On Wed, Jan 21, 2015 at 5:28 PM, Salz, Rich <[email-masked]> wrote:
> That's a pretty weighty assumption.  And how do you decide which ones you have to support, which are MTI, etc?

The ones that you need to support are the suite(s) specified as MUST
in the TLS 1.3 RFC.

>  How do you advise customers to use OCB over their favorite national cipher, like GOST or SEED?  Or Camellia?

Apples and oranges; AFAIK OCB is a generic mode, so presumably there
will be at least an ID for Camellia/OCB mirroring the AES/OCB cipher
suites as soon as the people at NTT wake up...

/grubba

-- 
Henrik Grubbström                                       [email-masked]
Roxen Internet Software AB                              [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Wed, 21 Jan 2015 10:45:49 -0600

> (10%) in the number of ciphers.

Cartesian explosion of unrelated things is a problem TLS has that it
doesn't need to have in 1.3.

Key exchange, server authentication, PRF, hash functions, and
cipher+mode, should all be negotiated separately (but cipher and mode
must be negotiated together).  Yes, in some cases key exchange and
server authentication can be very closely tied, e.g., RSA key transport.
SSHv2 gets all of this right; why can't TLS 1.3?

> We need a cipher cage match.  They call go in, and only a couple come

That seems unrealistic :(

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 21 Jan 2015 10:50:13 -0600

> > I don't see how these would be relevant to embedded devices.

If DHE_PSK is relevant to an embedded device then all cipher+mode
combinations might be as well.  Obviously OCB wouldn't be required to
implement, but that's no reason to exclude any one subset of ciphersuits
using OCB.

> If we generally think DHE_PSK is a good idea, is there a specific
> reason why it wouldn't be a good idea for OCB?

There isn't.  Embedded devices need not implement the full set of
suites.

But really, this is once more about the gross inefficiency (in terms of
registration as well as number of bytes used on the wire) of cartesian
explosion ciphersuites.  Can we fix this?

Nico
--

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 21 Jan 2015 17:58:57 +0100

Hi,

> We need a cipher cage match.  They call go in, and only a couple come out.

I'm not opposed to that. And am sure OCB would win over e.g. CCM. Also:
I'm not suggesting OCB mode should be MTI. That's up to the people
currently spec'ing TLS 1.3. GCM based ciphersuites seem like a good idea
to be MTI. e.g. CCM do not.

BTW: Amazed to find out that GOST is still in use (and still mandatory
for russian gov./banking?).

> implement, but that's no reason to exclude any one subset of ciphersuits

Well. No. Not really. Why would an embedded device prefer to do DHE over
ECDHE? ECC operations are sure to be more efficient on embedded
devices/IoT. That's was my reason to ask for removal.

> There isn't.  Embedded devices need not implement the full set of

+1

> explosion ciphersuites.  Can we fix this?

What's your suggestion to fixing this? I totally agree that there are
far too many ciphersuites around, which is somewhat ironical because I
just suggested adding 10-12 more. But I'd really like to see and use OCB
mode over CCM in TLS. This is also the reason I'm trying to get rid of
as many unnecessary (or insecure) ciphersuites as possible for OCB.

Aaron

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 21 Jan 2015 17:01:33 +0000

> BTW: Amazed to find out that GOST is still in use (and still mandatory for
> russian gov./banking?).

Still in use, and a new version just came out and an OpenSSL ticket filed to support it.

Tnx for your explanation on the other stuff.

---

From: Nico Williams <[email-masked]>
Date: Wed, 21 Jan 2015 11:09:26 -0600

> devices/IoT. That's was my reason to ask for removal.

Sure, but why not just deprecate/remove non-ECDH ciphersuites and be done?

> What's your suggestion to fixing this? [...]

Negotiate key exchange, server authentication, PRF, hash, and
cipher+mode separately.  (Cipher and mode go together, as not every mode
makes sense for every cipher, but key exchange should have no relation
to the choice of cipher+mode.)  Key exchange and server authentication
are closely tied in some cases (e.g., RSA key transport), but that's not
a problem (SSHv2 managed).

Nico
--

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 21 Jan 2015 20:14:07 +0300

Helo all,

> for russian gov./banking?).

Yes, it's still in use. And new algorithms appeared in 2012.

-- 
SY, Dmitry Belyavsky

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 21 Jan 2015 18:20:16 +0100

> Sure, but why not just deprecate/remove non-ECDH ciphersuites and be done?

That'd be the best option, I agree. But Nikos pointed out that people
might still want PSK without diffie-hellman at all for confined
environments/embedded. Otherwise I wouldn't have put it in there in the
first place. I'm happy to remove these ciphersuites if there's consensus.

> a problem (SSHv2 managed).

Sounds like a plan. But more like something for the TLS spec than this
ID, right?

RSA as key transport doesn't concern this ID anyway. And AFAIK it's
going deprecated with TLS 1.3 because of security concerns. I've even
explicitly stated it in the security considerations section of my ID.

Aaron

---

From: Jack Lloyd <[email-masked]>
Date: Wed, 21 Jan 2015 17:27:48 -0500

> https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/

My initial understanding on reading the draft was that in the nonce construction
the sequence number is implicit (or already explicit in the message in the case
of DTLS), and the record_iv_length of these ciphersuites is zero. However it
then refers to RFC 5288 (the GCM ciphersuite definition), which includes an
explicit 8 byte nonce in each message. Or is this reference purely with regards
to the formatting of the nonce input to the AEAD algorithm? Even just an
additional statement "The record_iv_length is X." should resolve this.

If anyone is interested in interop testing, I have implemented these ciphersuites
(assuming record_iv_length is 0) for the next release of botan (available via
https://github.com/randombit/botan) using ids in the private use range.

Cheers,
  Jack

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 22 Jan 2015 00:58:08 +0100

Hi Jack,

Jack Lloyd wrote:
> explicit 8 byte nonce in each message. 

Good catch!

> Or is this reference purely with regards to the formatting of the nonce input to the AEAD algorithm? 

Yes.

> Even just an additional statement "The record_iv_length is X." should resolve this.

I'm in the process of editing the draft and will add this information to
it. Do you want to suggest a paragraph/sentence or do you think this
will suffice for implementors?

> https://github.com/randombit/botan) using ids in the private use range.

Nice. I always liked Botan (I knew it supported OCB - Sorry for failing
to mention you guys in my initial message), thanks for being so quick to
adapt your codebase to my ID!

(OT: I'd really like to see usable Python bindings for Botan.)

Aaron

---

From: [email-masked] (Martin Rex)
Date: Thu, 22 Jan 2015 04:33:12 +0100 (CET)

> Still in use, and a new version just came out and an OpenSSL ticket filed

The closest thing to a public specification is a long expired I-D:

  https://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04

with essentially one TLS cipher suite TLS_GOSTR341001_WITH_28147_CNT_IMIT
that uses an officially deprecated/retired algorithm (R 34.10-2001)
and lacks the code point assignments that would be necessary for use
with TLSv1.2.

Googling just now, I found what might be a potential spec update:

https://www.cryptopro.ru/sites/default/files/products/csp/rus-popov-tls-gost-00-rf.pdf

but I don't understand russian.

The TLS parameters code point assignments in the new document seem to
be from the private use areas (cptls-04 had kidnapped the cipher suite ids).

-Martin

---

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 22 Jan 2015 08:20:09 +0300

Hello Martin,

> be from the private use areas (cptls-04 had kidnapped the cipher suite
Yes, it's a new specification updated for using new GOST signature and
digest alorithms. It does not take into account TLS 1.3 specification at
all.
The R 34.10-2001 algorithm is not deprecated yet but will be deprecate soon.

-- 
SY, Dmitry Belyavsky

---

From: [email-masked] (Martin Rex)
Date: Thu, 22 Jan 2015 07:25:40 +0100 (CET)

Dmitry Belyavsky wrote:
> 
> Martin Rex <[email-masked]> wrote:
>>

The 2009 spec precluded that a TLS client could offer TLSv1.2 and
GOST in the same ClientHello (due to the lack of code point assignments)

It would really facilitate interop (and review/feedback) when the
new/updated specification could be translated and published in English.

> The R 34.10-2001 algorithm is not deprecated yet but will be deprecate soon.

This is how I read and understood this:

  https://tools.ietf.org/html/rfc7091#section-1.1

   GOST R 34.10-2001 is superseded by GOST R 34.10-2012 from 1 January
   2013.  That means that all new systems that are presented for
   certification MUST use GOST R 34.10-2012 and MAY use
   GOST R 34.10-2001 also for maintaining compatibility with existing
   systems.  Usage of GOST R 34.10-2001 in current systems is allowed at
   least for a 5-year period.

Reality does not always follow plans -- similar to the planned published
sunset date (end of 2010) for SHA1-based digital signatures in
US NISTs SP800-57 Part1 rev2 (March 2007)...

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 22 Jan 2015 09:37:35 +0100

> devices/IoT. That's was my reason to ask for removal.

It will not. However, there will be no PFS fallback if for some reason
there is some attack on ECDHE that is not applicable on DHE. In any case
I don't find the issue critical. Even if removed it's only 2
ciphersuites saved, and we are nowhere close to believing that the
ciphersuite space is close to an end.

regards,
Nikos

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 22 Jan 2015 17:47:28 +0100

Hi Nikos,

> ciphersuite space is close to an end.

Yes I agree. The issue I see is that confined/embedded might not have
DHE as fallback in any case, because they probably opt to not support it
because if plattform constraints. And as far as I understand PSK is
exactly there for these use-cases. It would be really good to have
someone doing TLS crypto in the embedded world comment on this topic.
I've done embedded development but nothing that touched TLS so far.

That being said: You're right. I'd much rather have it in there than
have no fallback.

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 22 Jan 2015 18:20:18 +0100

Hi TLS-WG,

I've uploaded an updated, edited version of the ID incorporating some
suggestions and changes that were pointed out to me in this thread:
http://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/

Diff:
http://www.ietf.org/rfcdiff?url1=draft-zauner-tls-aes-ocb-00&url2=draft-zauner-tls-aes-ocb-01

git History:
https://github.com/azet/draft-zauner-tls-aes-ocb/commits/master

Feedback as always appreciated.

Aaron

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 22 Jan 2015 18:28:04 +0100

On Thu, 2015-01-22 at 17:47 +0100, Aaron Zauner wrote:
> because if plattform constraints.

Hi,
 I don't think you should associate TLS-PSK with embedded systems only.
In RFC7360 you'll see DTLS used with PSK for the radius protocol, which
is implemented in a bigger variety of systems than embedded.

regards,
Nikos

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 22 Jan 2015 20:49:35 +0100

> is implemented in a bigger variety of systems than embedded.
Did not know this RFC. Thanks for pointing it out.

In the edited/updated ID I've left all the PSK ciphersuites untouched.

Aaron

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 22 Jan 2015 15:22:19 -0500

> is implemented in a bigger variety of systems than embedded.

There's also talk (for TLS 1.3) about eventually collapsing three
mechanisms we currently have into one:

 * PSK
 * session tickets
 * session ids

It looks like these can all be handled in the same way, which could
potentially make a TLS 1.3-only (or 1.3-and-later) implementation
simpler, because it would have fewer codepaths to follow and options to
keep track of.

        --dkg

---

From: "Jack Lloyd" <[email-masked]>
Date: Fri, 23 Jan 2015 10:37:11 -0500

> will suffice for implementors?

Just that statement probably is sufficient, but to minimize the number
of misinterpretations possible maybe something like this is better -

"""
The nonce input to the AEAD is described above using the TLS
presentation language. All values are represented in big-endian form
when constructing the AEAD input.

The sequence number of a message is always known to the receiver
through other means (either implicit protocol state or a per-message
header in the case of DTLS), so the nonce construction used does not
require any extra per-message information. Thus the record_iv_length
is zero (0) for all ciphersuites defined in this document.
"""

Cheers,
  Jack

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 23 Jan 2015 16:59:49 +0100

> is zero (0) for all ciphersuites defined in this document.
Thanks a lot! I'll add those paragraphs to the document. The current
revision has just the single sentence in it.

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 26 Jan 2015 17:42:20 +0100

Hi TLS-WG,

I've uploaded a new revision of my ID to the IETF website.

All suggested changes have been made. Further discussion and review is
very welcome.

```
Name:		draft-zauner-tls-aes-ocb
Revision:	02
Title:		AES-OCB (Offset Codebook Mode) Ciphersuites for Transport Layer
Security (TLS)
Document date:	2015-01-26
Group:		Individual Submission
Pages:		7
URL:
http://www.ietf.org/internet-drafts/draft-zauner-tls-aes-ocb-02.txt
Status:         https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/
Htmlized:       http://tools.ietf.org/html/draft-zauner-tls-aes-ocb-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-zauner-tls-aes-ocb-02
```

So far I've seen quite some support for this document and only a few
people disagreeing with -- in particular -- adding more ciphersuites to
the registry. I think OCB is a very good alternative to CCM and also
GCM. Would the WG be willing to take it on as a WG item/document?

Thanks,
Aaron