Re: [TLS] integrity only ciphersuites

Hi Geoff and Richard,
Thanks for raising these points….please see below for my comments:

From: Richard Barnes <rlb@ipv.sx>
Date: Tuesday, August 21, 2018 at 07:06
To: "geoffk@geoffk.org" <geoffk@geoffk.org>
Cc: "ncamwing@cisco.com" <ncamwing@cisco.com>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] integrity only ciphersuites

On Mon, Aug 20, 2018 at 7:46 PM Geoffrey Keating <geoffk@geoffk.org<mailto:geoffk@geoffk.org>> wrote:
"Nancy Cam-Winget \(ncamwing\)" <ncamwing=40cisco.com@dmarc.ietf..org<mailto:40cisco.com@dmarc.ietf.org>> writes:

> In following the new IANA rules, we have posted the draft
> https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-00
> to document request for registrations of HMAC based cipher
> selections with TLS 1.3…..and are soliciting feedback from the WG on
> the draft and its path forward.

This draft needs more security analysis than is currently there, and
probably it needs to define not just a ciphersuite but an entire
profile for using TLS with this ciphersuite.  Some topics:

* Anything that relies on EncryptedExtensions should probably not be
used.
[NCW] Thanks for raising this; I will have to review these and perhaps update the draft with appropriate consideration for them.

* The session ticket properties change in the absence of encryption.  In
existing TLS 1.3, they are sent only after Finished and so are
encrypted; now they are public.  I am not sure if this changes the
security model but it definitely makes it easier to attack the ticket.
[NCW] I’m not sure the quantifiable ease is significant (unless the session ticket has been weakly encrypted by the server); but we can certainly add that into the security considerations.

* A less-obvious consequence to the lack of confidentality is that a
typical implementation, an attacker can selectively block messages
knowing their contents (by breaking the connection).  In the weather
example this might be used to manipulate average daily temperature by
blocking only higher or only lower readings.  In the robot example
this might be used to cause it to exceed its limits by allowing
movement commands only in one direction.
[NCW] From an attack perspective, your description seems to imply selective message blocking which am not sure would be easily achieved in the use cases we listed as breaking the connection would likely imply a session teardown as well.

I wonder whether it's really helpful to call the result 'TLS' and
not something else?

I'm agnostic w.r.t. confidentiality of application data -- we've historically been bad at making decision about what does / does not need to be confidential, but hey, it's your data.
[NCW] This is an unfortunate truth :-P

However, the EE / NST arguments Geoff make here seem pretty compelling to me.  They indicate to me that if a mechanism is defined where application data is not encrypted, records that contain non-application data still need to be encrypted.  That of course blows away the "code footprint" argument, and it's not trivial to implement given how the application_data content type has been overloaded in 1.3.

ISTM that in order to do this at all elegantly, you'd have to abandon using application_data records for application data, since those have to be encrypted for the above reasons), and instead either:

- Use a different record type (say plaintext_data)
- Use a different protocol that can be muxed with TLS (as with DTLS-SRTP)

Unfortunately the former approach would require a Standards Action.  So maybe the latter is the way to go.
[NCW] I need to review the EE to ascertain the need for this….that is, if these indeed need to be encrypted as well as mac’d….

--Richard

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls