Subject: [TLS] TLS Interim - update and agenda

From: Joseph Salowey <[email-masked]>
Date: Tue, 3 Mar 2015 16:06:22 -0800

If you are planning on attending the interim meeting and you have not
received an email from me about Logistics for TLS interim meeting then you
need to contact me so I know you are coming.

The agenda for the interim is available here:

http://www.ietf.org/proceedings/interim/2015/03/10/tls/agenda/agenda-interim-2015-tls-1

This is a working session so we will be making adjustments as needed.

Thanks,

Joe

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Mar 2015 15:08:40 +0200

Will there be an audio stream or at least a recording?

> On Mar 4, 2015, at 2:06 AM, Joseph Salowey <[email-masked]> wrote:
> 
> If you are planning on attending the interim meeting and you have not received an email from me about Logistics for TLS interim meeting then you need to contact me so I know you are coming.
> 
> http://www.ietf.org/proceedings/interim/2015/03/10/tls/agenda/agenda-interim-2015-tls-1 <http://www.ietf.org/proceedings/interim/2015/03/10/tls/agenda/agenda-interim-2015-tls-1>
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Benjamin Beurdouche <[email-masked]>
Date: Wed, 4 Mar 2015 14:49:10 +0100

> On 04 Mar 2015, at 14:08, Yoav Nir <[email-masked]> wrote:
> 

+1 for recording if possible =)

B.

---

From: Sean Turner <[email-masked]>
Date: Thu, 5 Mar 2015 19:03:03 -0500

Stay tuned for webex details.

spt

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 8 Mar 2015 20:03:10 +0200

> http://www.ietf.org/proceedings/interim/2015/03/10/tls/agenda/agenda-interim-2015-tls-1

Since I won't be participating, here are some comments and thoughts about
items on the agenda:

Backwards compatibility:
------------------------
Is this about what is needed for compatiblity with past TLS versions?

If so, the things that I think need preserving are:
- ClientHello record header, message header and overall format.
- ClientHello being the only mandatory message in its flight.
- ServerHello record header, message header and version field (first two
  bytes).
- Signature TBS must not cause undesirable interactions with signature
  TBS in past versions.
- The first byte of record header needs to remain subprotocol id (for
  muxing TLS with other stuff)
- If finished messages get removed or changed to be just markers,
  deriving replacement TLS-unique value.
- Having drop-in replacement for TLS-Extractor.

The first three are about downnegotiation being possible without delay,
the fourth is about cross-protocol interactions, and the last three
are about application compatiblity.

Other than theses, I don't see much backwards compat concerns. In
practicular, the handshake changes tend to screw everything that isn't
aware of TLS 1.3 but tries to interpret it.

Or is this about dealing with the 1%+ TLS 1.3 intolerance?

0-RTT:
------
Although basic 0-RTT is essentially just strapping AEAD cipher to
IES (asymmetric encryption using DHFs) using parameters preprovisioned
by the server (or just plain AEAD if resuming), there are more subtle
things:

- Can replay protection be realistically provoded?
- If replay protection can't be provoded, authenticating the
  early data is just plain dangerous.
- Authentication here is very easy to get wrong, even if one somehow
  gets replay protection.
- Even without authentication, this could be useful for protocol banner
  exchange, speeding up protocol startup (and replaying protocol
  banners does not seem to be useful for attackers).

Tickets/Resumption/PSK:
-----------------------
- Tickets or resumption should not compomise FS (by storing MS).
- Can resumption be ratcheded even for re-resumptions (so re-resumption
  doesn't put resumed sessions at risk)?
- Tying resumption to PSK might cause issues with PSK identity
  selection.
- PSK identity selection can require 2RTT in some cases supported
  by TLS 1.2 (plus new messages and changes to messages).
- PSK adds a fair chunk of complexity.

OPTLS:
------
OPTLS can be viewed as two-level key scheme.

The usual benefits of two-level key schemes:
1) Potential for speed enhancement by quickly rotating weaker keys
   (weaker crypto is usually faster).
2) Better isolation of higher key.
3) Allowing quick rotation of lower key.

The drawbacks are that now one has a key that can sign quite damaging
things, and this mechanism increases complexity (by having second
certificate mechanism that works in different way).

However, the higher-level key might be more protectable than sole
key (it may be possible to apply more checks). If attacker just steals
the higher key, you are as screwed as currently.

As for revocation of lower key, it should be noted that in present
WebPKI, realistic revocation times are a day or two. Of course, trying
to push validity period down, one runs into issues with clock skew
(no secure time protocol!).

Also, if one tries to enhance performance, OPTLS inherently ties the
lower key strength with encryption strength, so if one uses weak
key, the encryption will also be weak (encryption strength and strength
of upper key are decoupled like with sole keys, in contrast to the usual
myth).

Also, I am not seeing solid peformance advantages (without HECC, which
currently is not usable).

In short, the worst downsides I see are:
- Extra complexity
- Revocation/expiry of lower-level keys.
- More things to potentially go wrong in development.
- Does not seem to provode solid peformance advantages.

Update/Rekey:
-------------
Rekeying needs to be stateless, so not to cause too much extra complexity
to TLS stacks and especially to applications.

In practicular, this means:
- Simultaneous rekeys are handled properly.
- ACKs can be delayed by an arbitrary amount (since no extra flights
  can be added).
- Rekey must not cause race conditions with TLS-Extractor.

Authentiation via update is very hairy due to application-level issues
it can cause (even if restricted to happen only once per connection).

Key hierarchy/derivation:
-------------------------
- Handshake master secret [hMS]
- Application CtS master secret [cMS] (derives from hMS)
- Application StC master secret [sMS] (derives from hMS)
- Extractor master secret [eMS] (derives from hMS)
- Resumption Premaster Secret [rPMS] (derives from hMS)

The earliest possible points of derivation (any earlier
runs into known problems):
- hMS: After Hellos&Shares
- cMS: After Hellos&Shares
- sMS: After Hellos&Shares
- eMS: After EncryptedExtensions
- rPMS: After entiere handshake

However, it might be better to derive cMS and sMS at respective
finished messages (or placeholders thereof), since that is just before
messages with those keys should start appearing (any earlier is an
error).

Signature format/orthogonal negotiation:
----------------------------------------
Is orthogonal negoiation about decoupling encryption, key exchange
and signatures from each other?

If so, recently I have heard of quite nasty comments about inability
of TLS to do that (these choices seem independent enough, to avoid
the "chinese menu problems").

Regarding signature format, isn't the current rule that the key
specifies the signature format (and then there is capability
advertisment)? Any reason that doesn't still work?

OHOH, CFRG might come up with some new signature format (e.g. something
based on EdDSA), should prepare for that.

I think the changes to add new signature format are:
- Codepoint for signature negotiation
- Format identifier for signature+hash combo (OID in case of X.509
  or RPK).

MTI cipher suites:
------------------
I see there being only two realistic AEAD ciphers:

- AES-GCM (if you have hardware support)
- Chacha20-Poly1305-AEAD (no need for hardware support)

Regarding key exchanges:

ECDHE: 
* NIST curves available (but violate crypto best practices)
* Brainpool curves available (but are slow)
* CFRG curves are not yet available (missing details, but
  I would be surprised if one isn't Curve25519 as-is)
DHE:
* Very slow. Scales badly.

Regarding signatures:

ECDSA:
* Quite crappy (behind the times even when invented, for apparently
  classified reasons).
RSA:
* Slow to sign. Scales badly.
<whatever CFRG comes up with>:
* Not yet.

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Sun, 8 Mar 2015 14:24:24 -0400

> MTI cipher suites:

On this topic, a thought to consider:
If Chacha20-Poly1305-AEAD were made MTI for TLS 1.3, that would greatly increase roll-out of the new cipher. AES-GCM could be listed as SHOULD support. Existing TLS 1.2 implementations generally support it already, so this would most likely provide two cipher suites that most can be expected to have available. On the other hand, if AES-GCM were chosen as MTI, then we would have to rely on merely encouraging implementations to consider alternatives.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 8 Mar 2015 11:36:15 -0700

On Sun, Mar 8, 2015 at 11:24 AM, Dave Garrett <[email-masked]>
wrote:

> If Chacha20-Poly1305-AEAD were made MTI for TLS 1.3, that would greatly
> increase roll-out of the new cipher. AES-GCM could be listed as SHOULD
> support. Existing TLS 1.2 implementations generally support it already, so
> this would most likely provide two cipher suites that most can be expected
> to have available. On the other hand, if AES-GCM were chosen as MTI, then
> we would have to rely on merely encouraging implementations to consider
> alternatives.

I tend to take the opposite attitude. The purpose of MTI is to provide a
guaranteed
minimum for interoperabilty, and given that GCM is generally supported, that
seems like the natural choice.

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Sun, 8 Mar 2015 14:50:04 -0400

On Sunday, March 08, 2015 02:36:15 pm Eric Rescorla wrote:
> On Sun, Mar 8, 2015 at 11:24 AM, Dave Garrett <[email-masked]> > wrote:
> I tend to take the opposite attitude. The purpose of MTI is to provide a guaranteed

It is of course the obvious choice, which is why I'm speaking up to encourage an alternative. TLS 1.3 is on track to have a one-true-cipher of AES-GCM, with alternatives slowly coming into play. This is something many would like to avoid, so a different decision here could affect that. ChachaPoly also has the benefit of playing nice with hardware, making MTI potentially easier on some. It's not a bad decision if AES-GCM is picked as MTI, but I do think it is very much worth considering the total end result and not just the minimum interop.

Dave

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 08 Mar 2015 20:01:34 +0000

On the question of MTIs...

I've no strong opinion on whether this would be good or bad, but
there is a perhaps-minor but real "rift" between devices supporting
GCM and those supporting CCM, and I've heard it postulated that
a cha-cha based ciphersuite could be the common denominator that
provides interop between those classes of device. I guess that's
an argument for making both ciphersuites MTI (note: I'm not claiming
it's a winning argument, but it is a thing to consider).

S.

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 09 Mar 2015 17:53:56 +0100

Hi,

> It is of course the obvious choice, which is why I'm speaking up to encourage an alternative. TLS 1.3 is on track to have a one-true-cipher of AES-GCM, with alternatives slowly coming into play. Th…

There's also my draft for AES-OCB. We're currently working out the IPR
situation (rogaway, IBM, etc.). I still think it's a viable option (more
than CCM) that should be considered /if/ there're no patent
restrictions. In the end CCM was developed because OCB was patented back
then.

On MTI:
- AES-GCM should be MUST not SHOULD.
- ChaCha20/Poly1305 should MUST as well.
..IMHO.

Aaron

---

From: Dave Garrett <[email-masked]>
Date: Mon, 9 Mar 2015 14:19:30 -0400

On Monday, March 09, 2015 12:53:56 pm Aaron Zauner wrote:
> There's also my draft for AES-OCB.
[...]
> - ChaCha20/Poly1305 should MUST as well.

Oh, I'd like to MUST all the things too, but I doubt that'd get consensus. Generally specs get exactly one MTI. One way to do things would be do do the following:

ChaCha20/Poly1305 MUST implement
AES-GCM SHOULD implement; MUST implement if TLS 1.2 backwards compatible
AES-OCB RECOMMENDED or SHOULD implement

TLS 1.3 implementations should be required to attempt better security when using old versions, so requiring AES-GCM to do so seems perfectly reasonable.

Dave

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 09 Mar 2015 19:32:07 +0100

Hi Dave,

> Oh, I'd like to MUST all the things too, but I doubt that'd get consensus. Generally specs get exactly one MTI. One way to do things would be do do the following:

Wouldn't it make sense in the case of TLS to have more than a single MTI
ciphersuite? Given that there are problems with AES-GCM on mobile
devices and ChaCha20 seems to be the contender for multi-plattform
ideally both would be mandatory? AES-GCM has huge performance benefits
on plattforms that do have AESNI instructions so having ChaCha as MTI
will cause implementors to implement both. That's good; but also a bit
confusing instead of having both as MTI. Is there a strong reason why
there _must_ be only one ciphersuite as MTI?

> TLS 1.3 implementations should be required to attempt better security when using old versions, so requiring AES-GCM to do so seems perfectly reasonable.

Exactly.

Aaron

---

From: Stephen Checkoway <[email-masked]>
Date: Mon, 9 Mar 2015 15:27:12 -0400

On Mar 9, 2015, at 2:19 PM, Dave Garrett <[email-masked]> wrote:

> Generally specs get exactly one MTI.

We should reevaluate that. Having a single MTI leads to situations like IMAP's STARTTLS (RFC 3501) which makes RC4 the only MTI.

-- 
Stephen Checkoway

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Mon, 9 Mar 2015 19:44:08 +0000

+1

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  <https://www.ll.mit.edu/labcertificateauthority.html>

----- Original Message -----
From: Stephen Checkoway [mailto:[email-masked]]
Sent: Monday, March 09, 2015 03:27 PM
To: Dave Garrett <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda)

-- 
Stephen Checkoway

---

From: Dave Garrett <[email-masked]>
Date: Mon, 9 Mar 2015 16:10:22 -0400

> We should reevaluate that. Having a single MTI leads to situations like IMAP's STARTTLS (RFC 3501) which makes RC4 the only MTI.

Honestly, I don't believe the existing policy is unreasonable. If implementers could actually be compelled to implement both, great, but RFCs can get ignored and in practice you could end up with only one... and no interop.

A bigger problem is that just specifying MTI isn't enough in practice. It would be better to have an MTI and a separate MTD (MTI + mandatory to deploy). For example, with RC4 being phased out I've actually got a report from someone who has a host that uses TLS 1.2 but with their MTI suite (AES-CBC) disabled, and only RC4 and Camellia supported. This shouldn't be a thing we have to worry about. If we picked an MTD and an MTI, that would be far more reliable. Both would of course be subject to revision in a future RFC, and it should probably state that up front. (instead of pretending that everything will be fine forever)

So, with this in mind, I'd suggest for TLS 1.3:

MTD: ECDHE ChaCha20/Poly1305 AEAD
MTI: ECDHE AES-GCM (possibly both ECDSA and RSA auth)

Also specifying MTI curves is probably a good idea at this point.

Dave

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 09 Mar 2015 22:12:12 +0100

Hi Dave, et al.,

> Honestly, I don't believe the existing policy is unreasonable. If implementers could actually be compelled to implement both, great, but RFCs can get ignored and in practice you could end up with o…

I don't see why having only one MTI ciphersuites would change that
outcome? If the RFC gets ignored anything could happen. A TLS
implementation that is unable to speak to other implementations is
pretty useless; that would probably also be the observation by the
implementers.

> A bigger problem is that just specifying MTI isn't enough in practice. It would be better to have an MTI and a separate MTD (MTI + mandatory to deploy). For example, with RC4 being phased out I've…

I get why some implementers (e.g. embedded people) would only want to
have to implement one ciphersuite. My concern is also for deployment. I
do believe (possibly naively) that most implementers will know what
their users need. But then again -- maybe I'm just confused by the term
(which should be defined in more detail, in case) -- but doesn't
mandatory to deploy also mandate that implementations do support the
specified ciphersuites in practice?

I don't think that just because something has been 'convention' for some
time it's always the best option (see postel's law). It might make sense
to reevaluate as others have also stated in this thread.

Again; are there serious concerns why there should not be more than one
MTI ciphersuite in the TLS 1.3 spec.?

> MTI: ECDHE AES-GCM (possibly both ECDSA and RSA auth)

That would be again more than one ciphersuite. So why not have more than
one but with different AEAD constructions?

BTW: I'm not convinced ECDSA is the best path to take [0]. AFAIK from
deployments most commercial CAs do not issue ECDSA certificates either,
unless that has changed significantly over the last year or so.

> Also specifying MTI curves is probably a good idea at this point.

AFAICT it'll take CFRG some more time until a recommendation can be
made. I don't believe it'd be a good idea for TLS-WG to specify a curve
before there is consensus within CFRG.

Thanks,
Aaron

[0] djb explains this in more detail over here:
    http://blog.cr.yp.to/20140323-ecdsa.html

---

From: Dave Garrett <[email-masked]>
Date: Mon, 9 Mar 2015 17:39:44 -0400

> specified ciphersuites in practice?

It's the difference between an implementation supporting the cipher and the deployment enabling the cipher. A connection proposing a cipher list without the MTI is still considered valid. One proposing without an MTD is essentially a protocol error.

We have three decision sets in TLS:

1) IETF TLS WG RFC -> The Specification
2) Software implementing #1 -> The Implementation
3) Administrators configuring #2 on their servers -> The Deployment

Unless it gets through all three, it doesn't actually end up on the Internet. The notion of MTI only covers us to #2. The notion of MTD gets to #3. Essentially, it's #1 telling #2 that they may not even provide an option to #3 to override the MTD decision by #1 (short of rewriting #2).

The HTTP/2 spec process also had discussions about being specific when referring to implementations vs. deployments, or being more general.

> time it's always the best option (see postel's law).

Very much so.

> MTI ciphersuite in the TLS 1.3 spec.?

What I'm proposing is essentially two MTI, with one that implementations are not allowed to disable. If you want to be really strict, endpoints could reject connections that do not propose the MTD, regardless of what's negotiated (but that has risks if the MTD needs revoking).

> one but with different AEAD constructions?

Not a bad idea. However, the more that is proposed, the higher risk of some implementation deciding to ignore something. (though, this assumption may not be true anymore)

> unless that has changed significantly over the last year or so.

If it's not used enough, then yeah, RSA only there. I only suggest it as an option.

> I don't believe it'd be a good idea for TLS-WG to specify a curve

I think finalizing the TLS 1.3 spec prior to finalized CFRG specifications would be a bad idea. Hopefully they're almost done arguing.

Dave

---

From: Yoav Nir <[email-masked]>
Date: Mon, 9 Mar 2015 23:42:05 +0200

> On Mar 9, 2015, at 9:27 PM, Stephen Checkoway <[email-masked]> wrote:
> 
> 

How many IMAP clients and servers support only RC4? If I configured my client or server to work with some popular ciphersuites (like AES-CBC 128-bit with SHA and either RSA or RSA_ECDSA) would I get failures?

The problem with >1 MTI is that it raises the bar for minimum-sized codebase, same as the old “all IPv6 implementations MUST have IPsec”. It’s not a problem for a server, a personal computer or even a phone to have two algorithms, but will that work for smartobjects?  I guess DICE or a successor might create a profile for smartobjects that has only one MTI despite what the TLS 1.3 document might say, just as previous working groups excused smartobjects from supporting IPsec. Do we really want to go there?

Yoav

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 09 Mar 2015 22:52:21 +0100

Hi Dave,

> 3) Administrators configuring #2 on their servers -> The Deployment

Thanks for clearing this up. This should be explained in case it ends up
in the I-D.

> What I'm proposing is essentially two MTI, with one that implementations are not allowed to disable. If you want to be really strict, endpoints could reject connections that do not propose the MTD,…

I'm fine with that.

> Not a bad idea. However, the more that is proposed, the higher risk of some implementation deciding to ignore something. (though, this assumption may not be true anymore)

I think the crypto community is pretty confident in AES. That being
said, different AEAD constructions would make sense in case there is new
research suggesting security issues with one of both. Be it MTI or MTD.

> I think finalizing the TLS 1.3 spec prior to finalized CFRG specifications would be a bad idea. Hopefully they're almost done arguing.

:)

Aaron

---

From: Dave Garrett <[email-masked]>
Date: Mon, 9 Mar 2015 18:21:40 -0400

> Thanks for clearing this up. This should be explained in case it ends up

Sorry for not being clear enough. The way I worded it initially was interpretable in multiple ways. (which I guess is apt for this discussion ;)

> > What I'm proposing is essentially two MTI, with one that implementations are not allowed to disable. If you want to be really strict, endpoints could reject connections that do not propose the MT…

The risks could be mitigated with some limit on when to bail entirely, though I don't know that could be specified in a way that won't cause interop problems. If we're confident that humans have finally figured out how to write cryptography in a way that won't have catastrophic failures anymore (stop laughing), then we'd just expect some minor interop breakage until implementations are updated after a deprecation/prohibition RFC for an MTD.

In my opinion, everyone is too afraid of breakage. We should just agree on how to break in unison in a way that maintains the best possible result.

> research suggesting security issues with one of both. Be it MTI or MTD.

Setting CBC aside, I agree. We're pretty much down to just AES-GCM being fully trusted, and that really needs to be fixed with more variants as well as new ciphers and new versions of old ciphers, like Camellia and GOST. Single points of failure are not a good thing.

> > I think finalizing the TLS 1.3 spec prior to finalized CFRG specifications would be a bad idea. Hopefully they're almost done arguing.

For those that haven't checked the CFRG recently, they've agreed on Curve25519 & Ed448. How long it will take to agree on how to specify this is anyone's guess.

Dave

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 9 Mar 2015 23:38:08 +0100

:)

> The risks could be mitigated with some limit on when to bail entirely, though I don't know that could be specified in a way that won't cause interop problems. If we're confident that humans have fi…

Sorry. I should have quoted properly. That wasn't supposed to sound
like 'fine with rejection'. I'm fine with having MTI and MTD, now
that it's clear to me what MTD is supposed to bring to the table.

> In my opinion, everyone is too afraid of breakage. We should just agree on how to break in unison in a way that maintains the best possible result.

I concur.

> Setting CBC aside, I agree. We're pretty much down to just AES-GCM being fully trusted, and that really needs to be fixed with more variants as well as new ciphers and new versions of old ciphers,…

I don't know if that's still an issue in implementations, but a
contributor and co-author of bettercrypto(.org) was told that
there're issues (IIRC timing attacks) with AES-GCM on some mobile
plattforms by Google people about a year ago. I just did a quick
Google search for that and all I could find was a paper by Emilia
Kaesper and Peter Schwabe from 2009 that apparently fixes this in
OpenSSL -- so I'm not sure what exactly they meant (I wasn't at the
conference myself).

In any case, people do argue that algorithmic agility causes more
problems than it's worth. I agree somewhat, but IMHO at least one
backup is a good idea (although I prefer N+2; e.g. AES-GCM, AES-XXX
and another cipher or the other way around) and I think we should
make it as simple as possible for implementers that these actually
end up deployed. +1 on MTD.

Aaron

---

From: Dave Garrett <[email-masked]>
Date: Mon, 9 Mar 2015 19:11:16 -0400

On Monday, March 09, 2015 06:38:08 pm Aaron Zauner wrote:
> backup is a good idea

I'd much rather have three than two. (not counting deprecated ciphers/modes) I think of it in this way: if one were to vanish, there would still be a choice left. With only two chosen ones, then a fatal attack on one brings us all the way back to the one-true-cipher again.

If you assume eventual failure, a secondary backup is very desirable.

Dave

---

From: Watson Ladd <[email-masked]>
Date: Tue, 10 Mar 2015 17:33:45 -0700

On Mar 9, 2015 4:11 PM, "Dave Garrett" <[email-masked]> wrote:
> I'd much rather have three than two. (not counting deprecated
ciphers/modes) I think of it in this way: if one were to vanish, there
would still be a choice left. With only two chosen ones, then a fatal
attack on one brings us all the way back to the one-true-cipher again.
> If you assume eventual failure, a secondary backup is very desirable.

Both AES-CCM and AES-GCM have security reducing to that of AES as a PRP. So
they aren't actually independent backups. The issue is that extremely
limited hardware may only support AES-CCM.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 10 Mar 2015 21:12:09 -0400

> limited hardware may only support AES-CCM.

Yes, to be clear, I'm saying we'd ideally want an ecosystem with 3 ciphers, not 3 cipher suites. (the discussion drifted and the words are fuzzy) Too few results in failing back to a risky point, and too many risks fragmenting cipher support and interop too much.

Referencing the whole zoo of newer AES AEAD modes in the TLS 1.3 spec is probably worthwhile, but picking just one for MTI probably means GCM. Hey, if we can do ~another~ MTI, we could go: Chacha/Poly + AES-GCM + one other AES mode, all MTI, with Chacha/Poly as MTD.

Dave

---

From: Brian Sniffen <[email-masked]>
Date: Thu, 12 Mar 2015 10:42:42 -0400

> AES-OCB RECOMMENDED or SHOULD implement

Does that imply that servers should prefer AES-OCB, AES-GCM, ChaCha20,
in that order?  If any other order, what's the point of including the
later ciphers?

I expect that implementations that have to use FIPS-only crypto will not
implement ChaCha20 no matter what is said here.

-Brian

-- 
Brian Sniffen
"I reserve the right to evolve my views, and state that views I previously
 expressed may have been somewhere along the spectrum from insufficiently
 nuanced through ill-informed to dead wrong."

---

From: Dave Garrett <[email-masked]>
Date: Thu, 12 Mar 2015 11:39:29 -0400

> in that order?  If any other order, what's the point of including the

I don't see any need to require implementations to prefer an order. The point is to have choices for different use cases, and to have backups in the event of one of them turning out to be broken.

Dave

---

From: Sean Turner <[email-masked]>
Date: Thu, 12 Mar 2015 18:24:03 -0400

> MTI cipher suites:

I’m going to start a thread specific to what was discussed in Seattle wrt algorithms.*  Not going to happen until at least tomorrow though.

spt

* Obviously, what we settled on will be confirmed on list and I have no doubt discussed in Dallas.