Re: [TLS] integrity only ciphersuites

[Richard Barnes <[e-mail]>]

On Mon, Aug 20, 2018 at 7:46 PM Geoffrey Keating <[e-mail]> wrote:

> "Nancy Cam-Winget \(ncamwing\)" <ncamwing=[e-mail]>
> 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.
>
> * 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.
>
> * 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.
>
> 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.

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.

--Richard


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