Subject: AEAD in ssh

From: [email-masked] (Niels Möller)
Date: Mon, 01 Feb 2016 22:55:40 +0100

denis bider <[email-masked]> writes:

> With regard to AEAD:
>
> I think we should just make the following simple and clear statement:
>
> MAC algorithms are secondary to encryption algorithms, and are
> evaluated only if the encryption algorithm is not AEAD. If an AEAD
> encryption algorithm is negotiated, the outcome of MAC negotiation is
> irrelevant and must be ignored. If no mutual MAC algorithms are
> available, this causes key exchange to fail if, and only if, the
> negotiated encryption algorithm is not AEAD.

That's only one part of it. I think the following points need clear
specification:

1. How to negotiate use of AEAD. 

   The above would work, I think. 

   Or one could specify a "n/a" mac name, which is a bit like "none",
   except that negotiation fails if it's the output of the mac
   negotiation and the negotiated cipher isn't an aead mechanism. Maybe
   unnecessary, but it could also serve the second purpose as signalling
   support for aead, in case the negotiation rules need tweaking (see
   also next point). If defined, it should be mandatory (i.e., if the
   agreed cipher is aead, but "n/a" mac isn't offered, connection should
   fail).

2. How it interacts with first_kex_packet_follows. 

   Roughly, if everything is "guessed" correctly except the mac
   algorithm (e.g, if the mac name-list is empty so mac negotiation
   fails), and the agreed cipher is aead, the guess ought to
   nevertheless be considered successful. The details must be made
   crystal clear. 

   (And I'm open to tweaking the rules in other ways too, if new rules are
   reliably signalled via some extension or by the "n/a" atom; it's
   unclear to me if the first_kex_packet_follows logic really needs to
   depend on anything else but the agreed key exchange mechanism and
   maybe host_key_algorithm (I think I can argue that it's independent
   of host_key_algorithm: Every reasonable keyexchange algorithm needs
   input from the client, and the key exchange signature must depend on
   that data. Hence the first kex packet should be independent of the
   signature)).

3. If and how to encrypt the length field. 

   My strong opinion is that it ought to be encrypted. A spec for AEAD
   in ssh should either specify fully how to do that, or give clear
   guidelines in case some details must be left to the specification of
   each AEAD mechanism. Roughly, one should use an independent cipher
   instance (distinct key or disjoint nonce sequence or distinct ctr
   value) to encrypt the length in a ctr-like mode.

4. What the "block size" used for padding purposes (RFC 4253, Sec. 6,
   "Binary Packet Protocol") should be. 

   AEAD in the abstract doesn't expose any block size, so I'd be
   inclined to say that we should always use 8, the ssh minimum. One
   could tie it to the underlying block cipher if there is one, but it
   makes little sense to me, given that it's the length *including* the
   length field which must be a multiple of the "block size". And with
   AEAD, the length field has to be separately encrypted, so by the
   current rules, we're always going to be unaligned anyway.

5. Precisely which bytes go into the AEAD nonce, data, and plaintext,
   when processing each packet.

   Perhaps we should first take a step back and look at the binary
   packet format:

      uint32    packet_length
      byte      padding_length
      byte[n1]  payload; n1 = packet_length - padding_length - 1
      byte[n2]  random padding; n2 = padding_length
      byte[m]   mac (Message Authentication Code - MAC); m = mac_length

    For AEAD, maybe it's better to think about it as applying the
    padding to the *plaintext*. Then the plaintext input to the AEAD
    algorithm would be

      byte      padding_length
      byte[n1]  payload; n1 = packet_length - padding_length - 1
      byte[n2]  random padding; n2 = padding_length

    These n1+n2+1 = packet_length bytes of cleartext are transformed
    using AEAD into packet_length+m bytes of ciphertext including an
    authentication data.

    For simplicity, drop all requirements on the padding length except
    keeping the lower bound n2 >= 4.

    The packet length field is encrypted separately producing 4 bytes of
    encrypted length preceding the AEAD ciphertext on the wire. It can
    also be included in the associated data, before or after encryption;
    I'm not sure if there's any real benefit in doing that, but it might
    make it a little more robust.

The existing RFC 5647 on aes-gcm is unclear on (1) and (2) (and
apparently not implemented that way in openssh). I disagree with its
choice for (3), this has been argued on the secsh list recently, I'll
not repeat it here. 

I think it gets (5) right (without deep thinking about it. I note that
it departs from RFC 4253 by not including an explicit sequence number in
the authenticated data). For (4), it specifies that AEAD plaintext
*excluding* the length field must be a multiple of 16. Which makes some
sense, but (i) departs from the original rules, and (ii) is of little
benefit, since gcm doesn't require the input to be an integral number of
AES blocks.

Openssh's chacha-poly1305 is also pretty important. I don't have their
details in front of me, but at least the length *is* encrypted, using an
independent chacha instance. And it doesn't agree with the (later)
definition of chacha-poly1305 in RFC 7539.

In short, to write a good specification will require some non-trivial
amount of work. And I think it's pretty important work. Do you agree?
Are there any objections to the above direction? (I already know some
dislike encrypted lengths). What are the chances to reach rough
consensus?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 1 Feb 2016 23:20:57 -0800

Hi Niels & denis,

> 1. How to negotiate use of AEAD. 

Rather than "n/a" as the atom, why not "AEAD" or "aead" so we are clear
about the intent? That said, I am fine with ignoring the Mac if the
'Cipher' is an AEAD like the OpenSSH folks do if that is helpful.

Technically, aren't both AES-GCM and ChaCha20-Poly1305 considered to be
Authenticated Encryption with Associated Data (AEAD) rather than being
either a Mac or a Cipher directly?

> 3. If and how to encrypt the length field. 

+1 on encrypting the length field.

fwiw: I agree on the overall direction you have written.

	-- Mark

---

From: Damien Miller <[email-masked]>
Date: Thu, 4 Feb 2016 12:50:07 +1100 (AEDT)

>    agreed cipher is aead, but "n/a" mac isn't offered, connection should

I prefer Denis' forumation (which matches what we in OpenSSH for AEAD)
ciphers, it's simpler, harder to get wrong and less likely to fail at
runtime through user misconfiguration.

The only cost is that the KEX code needs to be able to easily
tell whether an algorithm is an AEAD before it starts working on
the MAC. The change to OpenSSH's KEX code to support AEAD ciphers
was trivial: https://anongit.mindrot.org/openssh.git/diff/kex.c?id=1d75abfe

>    that data. Hence the first kex packet should be independent of the

I don't think the first_kex_packet_follows rules need adjustment if
mac negotiation is simply ignored for ciphers that are AEAD.

>    value) to encrypt the length in a ctr-like mode.

IMO this is completely up to the AEAD itself. OpenSSH supports an AEAD that
does (chacha20/poly1305) and AES-GCM that doesn't. I'm not convinced that
encrypting packet lengths wouldn't contribute to an effective traffic
analysis mitigation scheme -- the "peek-a-boo" paper clearly shows they
are not sufficient, but that's not the same as saying that it isn't
necessary, or can't help.

OTOH I'll freely admit that the point is moot in the absense of a
threat model and until implementations actually implement serious
traffic analysis mitigations.

I don't accept Peter's argument that encrypting length fields
is a net negative for security. An independently keyed cipher for
length encryption is never going to act as an oracle in the same
way as the CBC+bad MAC order mess was.

>    current rules, we're always going to be unaligned anyway.

I don't think it makes sense to try to define this for AEAD modes in
abstract, it's a concrete property of the individual algorithms.

> apparently not implemented that way in openssh).

RFC5647 is quite clear on negotiation, but it doesn't follow either
scheme mentioned above (with are both IMO much more reasonable),
instead it requires (section 5.1) that "AEAD_AES_*_GCM" be selected
for both cipher and MAC. I think this offers even more opportunities
for runtime failure and misconfiguration.

> dislike encrypted lengths). What are the chances to reach rough

IMO the best approach to the problem is to define the right way to
negotiate AEAD algorithms in KEX, but specify the AEADs individually.

If I had a time machine then I'd go back to 2000, buy a bunch of
stocks and then argue that SSH2 should only negotiate complete AEADs
rather than separate ciphers and MACs. I'd almost certainly be
dismissed as a crank, but at least I'd be rich when I got back.

-d

---

From: [email-masked] (Niels Möller)
Date: Thu, 04 Feb 2016 10:53:57 +0100

> mac negotiation is simply ignored for ciphers that are AEAD.

I think it just needs to be a little clearer. You mean that "ignored"
implies "considered a successful guess for purposes of the
first_kex_packet_follows logic", right?

> IMO this is completely up to the AEAD itself.

Since there isn't a single obvious way to do length encryption, I think
an ssh-aead is a good place to document some reasonable way to do it.
Possibly as a SHOULD (i.e., the spec for each particular AEAD should
stick to this particular way unless there's a good reason not to), but
not a MUST.

> abstract, it's a concrete property of the individual algorithms.

An AEAD algorithm as defined in RFC 5116 has no block size. Do you see
any advantage in making sure that the message size aligns with any block
cipher underlying any aead algorithm? If the alternative is to either
stick with 8 and the original size alignment rules, or to drop the
requirement that sizes align with any block size?

If we want to leave open for using an algorithm-specific block size, I
guess we have to do it like aes-gcm (RFC5647) and align things so that
the size of the aead plaintext input matches that block size, not
counting the length field like for non-aead ciphers. Right?

I think it is quite important to specify this in a uniform way for aead
algorithms. It should be easy to plug in any AEAD adhering to the
interface specified in RFC5116, without having to write new code to
ensure correct ssh packet sizes. (Which is why I'd also like to specify
some general and reasonable way to do length encryption).

> negotiate AEAD algorithms in KEX, but specify the AEADs individually.

In principle, I agree. But I think it will make better progress to have
at least one aead in the spec, both to help iron out the details, and to
get some concrete and good aead standardized faster (I don't quite like
gcm).
 
> rather than separate ciphers and MACs.

I don't think the ssh protocol design was controversial at all back
then. E.g, Schneier's Applied Cryptography, the bible at the time,
recommended doing the MAC on the plain text rather than the cipher text.
IIRC.

Regards,
/Niels

---

From: [email-masked] (Niels Möller)
Date: Thu, 04 Feb 2016 13:09:05 +0100

> 'Cipher' is an AEAD like the OpenSSH folks do if that is helpful.

Should we allow advertising an empty mac list when all advertised
ciphers are aead?

RFC4253, Sec 7.1., is quite clear that "Each name-list MUST contain at
least one algorithm name.". Is it ok to depart from that? Otherwise we
need some placeholder, be that "n/a" or "aead". (Or perhaps we could use
"none" in the particular case that *all* ciphers are aead, but I kind-of
dislike ever adding "none" to these lists, it's about as appropriate in
this case as using "hmac-md5", which would actually work just as well).

Rereading 4253, it also seems I misremembered the current spec of
first_kex_packet follows. It says

   o  the kex algorithm and/or the host key algorithm is guessed wrong
      (server and client have different preferred algorithm), or

   o  if any of the other algorithms cannot be agreed upon (the
      procedure is defined below in Section 7.1).

so maybe no tweaks needed there for aead. If the dependence on host key
algorithm is confusing or improper, that's an independent issue,
unrelated to aead.

I'm also happy to say that I've gotten some time to work on a draft.
Hopefully I have something within a few days.

Regards,
/Niels

---

From: [email-masked] (Niels Möller)
Date: Mon, 22 Feb 2016 09:47:44 +0100

> Hopefully I have something within a few days.

I've now posted a first version,
https://www.ietf.org/id/draft-nisse-secsh-aead-00.txt. I was advised by
a collegue with a bit more ietf experience to include one concrete AEAD.
So I added chacha-poly1305, to define something which is actually
implementable.

Regards,
/Niels

---

From: [email-masked] (Niels Möller)
Date: Wed, 24 Feb 2016 07:00:28 +0100

Watson Ladd <[email-masked]> writes:

> There already is a widely used SSH implementation with AEAD support. Copy
> what they do.

I'm aware of three different ways:

1. aes-gcm, according to 5647, implemented by some.

2. aes-gcm, according to openssh (with simpler negotiation rules, which
   I *do* copy).

3. chacha20-poly1305 according to openssh.

I think the time is right to try to document a recommended way to do it.

Regards,
/Niels

---

From: [email-masked] (Niels Möller)
Date: Tue, 23 Feb 2016 16:56:19 +0100

Bryan Ford <[email-masked]> writes:

> I see that in 3.1 on “Encrypting the packet length”, you’ve suggested
> the same approach as one of the earlier approaches I suggested a while
> ago in the corresponding TLS discussion. That’s a reasonable approach
> and I think would work, but I wanted to make sure you’re aware of
> another alternative that I’ve come to think is both cleaner and safer:
> just embed the length of the next packet within the normal
> AEAD-encrypted payload of its immediately prior packet.

Thanks for the update. 

This could make a lot of sense for a new protocol or for a larger
protocol update. But I think adding the length field to the preceding
packet is a too large structural change of the ssh protocol to do just
to support AEAD ciphers.

Regards,
/Niels

---

From: [email-masked] (Niels Möller)
Date: Wed, 24 Feb 2016 07:15:49 +0100

denis bider <[email-masked]> writes:

> I think lengths in AEAD
> should just be encrypted with the same underlying block cipher in CTR
> mode. No AEAD instance required.

What do you think of the way it is specified in the draft? Which
is well defined for an arbitrary AEAD, but boils down to plain CTR mode for
typical AEAD block cipher modes, and boils down to plain cacha encryption
for chacha-poly1305? 

I think it is elegant, but it's not the only way of course. Closest
alternative would be to use a separately keyed cipher (i.e., a larger
output from session key generation) and leave to the particular AEAD to
specify the cipher and how to use it.

Thinking aloud, I think the drawback of doing that is that it leaves
several arbitrary choices open, e.g., should lengths conceptually be
packed back to back into a stream to be encrypted four bytes at a time
(with AES-CTR, using the same block for four messages, and 16 messages
for chacha), or should we use one underlying "block" per message? I
would prefer consistency, and I don't see any drawback in trying to nail
these things down.

Regards,
/Niels

---

From: [email-masked] (Niels Möller)
Date: Tue, 23 Feb 2016 19:41:48 +0100

Bryan Ford <[email-masked]> writes:

> I can understand that position. However, one potentially
> counter-balancing consideration is that the introduction of new
> AEAD-based ciphersuites inherently introduces a new,
> wire-protocol-incompatible “record format” anyway that needs to be
> negotiated.

I agree, but at least it's only a different per-packet transformation.
Having to guess future packet sizes or emit extra packets is much more
than a new record format. I don't think it's a good tradeoff, too much
new complexity for little benefit.

My understanding is that cleartext length fields are believed to be
secure, in that the only thing leaked are message boundaries. And hiding
them using a separate stream cipher is a simple way to stop that leak
(and the benefit of doing that is under debate). In particular, the even
simpler alternative, to apply the AEAD to the 4-byte length field,
including authentication, seems like overkill. 

I think simplicity is essential for making progress here, if we go for a
design of ssh version 3, discussion will never end.

> Deferring useful record format changes until the next major protocol
> version,

I don't expect any need for a new major version of the ssh protocol for
the next one or two decades. It's not too painful to add aead support
(and all other additions of new algorithms have been smooth, as far as I
can tell).

Regards,
/Niels

---

From: denis bider <[email-masked]>
Date: Tue, 23 Feb 2016 22:09:46 +0000

That implementation, with unencrypted packet lengths, sabotages any hope of thwarting traffic analysis, even through high-overhead SSH_MSG_IGNORE padding.

If someone wants to do max bandwidth padding right now, using AES-CTR, they can just do it. With AES-GCM, this is no longer viable. Internal padding is too inflexible.

I think it's a shame to throw away implementation potential just because it's not currently being used. Right now we don't do max bandwidth padding because it's seen as inefficient. That may no longer be the case in 10 years.

25 years ago, encryption seemed inefficient, and no one did it.

Watson Ladd <[email-masked]> , 2/23/2016 6:57 PM:

 > (and all other additions of new algorithms have been smooth, as far as I

There already is a widely used SSH implementation with AEAD support. Copy what they do.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 23 Feb 2016 10:57:25 -0800

---

From: denis bider <[email-masked]>
Date: Tue, 23 Feb 2016 22:00:21 +0000

I've recently been implementing AES-GCM, and it has so far involved considerable architectural changes. The Bitvise SSH implementation abstracts cryptography into a pluggable crypto provider. Previously, the API to the crypto provider was low-level, and the SSH implementation made the calls to encrypt, decrypt, and calculate MAC. In order to implement AEAD, this had to be turned on its head, so that the interface to the crypto provider is now fairly high-level. The crypto provider must now have awareness of the SSH packet format. To keep the same interface for AEAD and traditional ciphers, I had to move the job of encrypting and decrypting a packet from the SSH implementation into the crypto provider. (The alternative would be to have two interfaces.)

My point is that implementing AEAD may likely require restructuring as it is. I'm not sure this is a reason to dismiss the idea of encrypting the length of the next packet as part of the previous packet.

A good reason to set it aside, I think, is that we have a solution that's architecturally simpler than this. I think lengths in AEAD should just be encrypted with the same underlying block cipher in CTR mode. No AEAD instance required.

Niels Möller <[email-masked]> , 2/23/2016 6:41 PM:

 

 
 
Regards, 
/Niels

---

From: Bryan Ford <[email-masked]>
Date: Tue, 23 Feb 2016 09:03:53 -0800

> packet is a too large structural change of the ssh protocol to do just

I can understand that position.  However, one potentially counter-balancing consideration is that the introduction of new AEAD-based ciphersuites inherently introduces a new, wire-protocol-incompatible “record format” anyway that needs to be negotiated.  No one will be able to decrypt a new AEAD-encrypted record anyway unless it understands the new AEAD spec; it wouldn’t be that hard for it to interpret the encrypted contents of that record a bit differently at the same time.  

This AEAD-induced incompatible change thus presents a natural point in time in which to introduce other (minor) changes relatively painlessly in the encrypted content of those records, without introducing any “new” negotiation mechanisms.  Just specify that all legacy (non-AEAD) ciphers always use the “old” internal packet format, and new (AEAD) ciphers always use the “new” internal packet format.

Deferring useful record format changes until the next major protocol version, in contrast, creates the risk that implementations of the next major protocol version will need to support at least (a) legacy non-AEAD ciphers using the old format, (b) AEAD ciphers using the old format, and (c) AEAD ciphers using the new format.  That’s more moving parts, more protocol complexity, and greater risk of security bugs compared with just being able to deal with situations (a) and (c) alone.

Just some tradeoffs to be considered anyway.

B

---

From: Bryan Ford <[email-masked]>
Date: Tue, 23 Feb 2016 06:15:52 -0800

> So I added chacha-poly1305, to define something which is actually

Looks good.  

I see that in 3.1 on “Encrypting the packet length”, you’ve suggested the same approach as one of the earlier approaches I suggested a while ago in the corresponding TLS discussion.  That’s a reasonable approach and I think would work, but I wanted to make sure you’re aware of another alternative that I’ve come to think is both cleaner and safer: just embed the length of the next packet within the normal AEAD-encrypted payload of its immediately prior packet.  

This approach avoids either breaking the AEAD abstraction, or having to “misuse” an AEAD as a stream cipher.  It improves efficiency by ensuring that the AEAD cipher primitive needs to be invoked per packet, not twice.  It improves security by ensuring that no packet-length field is ever used in any way by the receiver before it’s been cryptographically authenticated.  In particular, it eliminates the classic vulnerability where an attacker can corrupt the length bits to make the length appear large and cause the receiver to hang indefinitely on a long socket read().

The obvious, and I think only, key question is how the sender “knows” in advance what length to promise for the next record, given that it can’t really see into the future.  But there are plenty of reasonable answers, from dead-simple to somewhat smarter.  A dead-simple sender could always send packets in pairs, the first being minimum-size (e.g., zero-payload-bytes) but indicating the second one’s length, the second packet containing the useful variable-length payload.  A slightly smarter sender could recognize when it has a lot of data buffered (e.g., during file transfer) and send runs of large packets and “promise” a minimum-sized one only when its tx buffer runs dry. 

A sender that pads for traffic analysis protection could always pad packets to the same length, and thus trivially knows what to “promise” in every packet.  A smarter sender with traffic analysis protection could pad packets to *multiples* of the same length opportunistically when there is enough data in the tx buffer; that’s more CPU- and bandwidth-efficient but to an adversary it still looks indistinguishable from N of the shorter packets.

There are more details in the relevant E-mails I posted back in December on the TLS list:

	- https://www.ietf.org/mail-archive/web/tls/current/msg18524.html
	- https://www.ietf.org/mail-archive/web/tls/current/msg18710.html

Cheers
Bryan

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 24 Feb 2016 09:50:27 +0000

Niels Möller <[email-masked]> writes:

>My understanding is that cleartext length fields are believed to be secure,
>in that the only thing leaked are message boundaries.

They actually leak nothing, in that encrypting the length provides no security
benefit at all.  See for example "Peek-a-Book, I Still See You: Why Efficient
Traffic Analysis Countermeasures Fail" by Dyer, Coult, Ristenpart and
Shrimpton. Their analysis, of TLS traffic with unencrypted lengths, completely
ignores TLS' plaintext length fields because they're irrelevant.

The encryption-of-lengths debate is a classic example of the assume-a-can-
opener problem:

  A physicist, a chemist, and an economist were stranded on a desert island
  with no implements and a can of food. The physicist and the chemist each
  devised an ingenious mechanism for getting the can open; the economist
  merely said, "Assume we have a can opener".

Instead of debating endlessly over the most efficient way to apply the assumed
can opener (encryption of lengths), we need to look at whether it serves any
purpose (as Dyer at el point out, it doesn't), and if it does serve a purpose,
whether it's worth the tradeoffs involved in implementing it (for which see
the previous point).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 24 Feb 2016 09:52:09 +0000

denis bider <[email-masked]> writes:

>That implementation, with unencrypted packet lengths, sabotages any hope of
>thwarting traffic analysis, even through high-overhead SSH_MSG_IGNORE padding.

With encrypted packet lengths and padding you're still not thwarting traffic
analysis, you're just making the job a lot more difficult for the implementer.
See my previous message.

Peter.

---

From: Damien Miller <[email-masked]>
Date: Thu, 25 Feb 2016 11:16:11 +1100 (AEDT)

On Wed, 24 Feb 2016, Peter Gutmann wrote:

> They actually leak nothing, in that encrypting the length provides no
> security benefit at all. See for example "Peek-a-Book, I Still See
> You: Why Efficient Traffic Analysis Countermeasures Fail" by Dyer,
> Coult, Ristenpart and Shrimpton. Their analysis, of TLS traffic with
> unencrypted lengths, completely ignores TLS' plaintext length fields
> because they're irrelevant.

Peek-a-Boo makes clear that encrypted lengths aren't *sufficient*, but
I don't think it's so clear that they aren't necessary or useful.

-d

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 25 Feb 2016 04:07:33 +0000

Damien Miller <[email-masked]> writes:

>Peek-a-Boo makes clear that encrypted lengths aren't *sufficient*, but I 
>don't think it's so clear that they aren't necessary or useful.

I assume you're referring to this subheading:

  Hiding packet lengths is not sufficient.

This is followed by:

  We initiate a study of classifiers that do not directly use fine-grained 
  features such as individual packet lengths. The VNG++ classifier just 
  mentioned uses only “coarse” information, including overall time, total 
  bandwidth, and size of bursts. In fact, we provide a naiive Bayes 
  classifier that uses only the total bandwidth for training and testing, 
  yet still achieves greater than 98% accuracy at k = 2 and 41% accuracy at 
  k = 128. 

So neither of the two classifiers they discuss use plaintext packet length 
information even though it's readily available.  They never really discuss 
whether it's useful or not since they're totally ignoring it, because their
analysis doesn't need it in order to work.

Peter.

---

From: [email-masked] (Niels Möller)
Date: Thu, 25 Feb 2016 07:19:16 +0100

> ignores TLS' plaintext length fields because they're irrelevant.

I've read that paper. It's good work, but I don't think it applies to all
uses of ssh, and it doesn't apply at all to high-overhead padding.

My understanding of that paper, as appliad to ssh, is that if you use
ssh to download files (e.g., using tcp forwarding of browser traffic),
the amount of data and the speed reveal a lot of what your downloading
and from where. But that's only one of many ssh use cases. I'm more
concerned about interactive use, in which case it may also be reasonable
to use high-overhead padding).

I agree completely that it's hard to defend against traffic analysis.
But I disgree with your judgment that encrypted lenghts are totally
useless period.

I would also like to say that the intention of my draft is to leave this
aspect of the protocol unchanged, because I think that's a decision
orthogonal to AEAD support. Conversely, if I wanted to add encrypted
length fields to TLS, I'd write a draft doing just that, not bundle that
change with standardization of some other new features.

Regards,
/Niels