Subject: [TLS] progressing draft-ietf-tls-encrypt-then-mac

From: Sean Turner <[email-masked]>
Date: Tue, 3 Jun 2014 20:49:33 -0400

draft-ietf-tls-encrypt-then-mac has completed WGLC, the latest version addresses all outstanding issues.  I’ve entered a Shepherd write-up, and am passing the buck to our AD.  Stay tuned for an AD review.

spt

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Jun 2014 11:37:25 +0100

On 04/06/14 01:49, Sean Turner wrote:
> draft-ietf-tls-encrypt-then-mac has completed WGLC, the latest
> version addresses all outstanding issues.  I’ve entered a Shepherd
> write-up, and am passing the buck to our AD.  Stay tuned for an AD
> review.

Thanks.

Got it. Will give it a read and get back in a couple of days.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Jun 2014 13:09:44 +0100

Hiya,

I got to this today in the end. I have one question only and
a couple of nits. Not sure if the answer to the question will
mean a change or not...

> write-up, and am passing the buck to our AD.  Stay tuned for an AD

section 3: "Once the use of encrypt-then-MAC has been
negotiated..." do you need to be more explicit about this?
The client clearly has to start by sending the extension, but
MUST the server also include the response extension as well,
or can a server just start using e-t-m if a client has sent
it the extension?  (You do say that if the server is using a
stream cipher or AEAD then the server MUST NOT send the
response extension.) This might be determined in 5246
already, but even so might be worth repeating here.

nits

- why the ' quotes in the abstract?

- intro: better to say "RFC 5246 [2] and..." rather than "[2]
and..."

Cheers,
S.

---

From: "Christian Kahlo" <[email-masked]>
Date: Wed, 4 Jun 2014 15:01:03 +0200

Hi there,

> version
> > addresses all outstanding issues.  I've entered a Shepherd write-up,
> > and am passing the buck to our AD.  Stay tuned for an AD review.
> 
> section 3: "Once the use of encrypt-then-MAC has been negotiated..." do
> you need to be more explicit about this?
> The client clearly has to start by sending the extension, but MUST the
> server also include the response extension as well, or can a server
> just start using e-t-m if a client has sent it the extension?  (You do
> say that if the server is using a stream cipher or AEAD then the server
> MUST NOT send the response extension.) This might be determined in 5246

writing as the guy who did the first public testable implementation
(eid.vx4.net) a server MUST send the extension if it was received from
the client and the server wants to negotiate ETM. Otherwise the client
wouldn't know how to encipher/decipher messages. This shouldn't be
implicit. The part about AEAD and stream ciphers is correct so far.

Best regards,
Christian