On Mon, Aug 20, 2018 at 7:46 PM Geoffrey Keating <geo...@geoffk.org> wrote:
> "Nancy Cam-Winget \(ncamwing\)" <ncamwing=40cisco....@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. > > * 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
