Re: [TLS] integrity only ciphersuites

+1 I fully understand the pursuit of minimizing complexity in TLS. However, banning from TLS all provisions to serve non-internet cases seems suboptimal to me. I think there is a whole universe of systems and applications that are just at the very beginning of being armed with security features:

[TLS] Suspicious behaviour of TLS server implementations

Dear all, we are working on an approach/framework for testing TLS implementations (currently only servers, but clients are planned for the future as well). While running our tests against a bunch of different TLS (server) implementations, we found several types of suspicious behaviour (see belo

[TLS] Antw: Re: Suspicious behaviour of TLS server implementations

and Cheers >>> Martin Thomson 10.09.16 12.39 Uhr >>> I think that Martin (R) provided you with the answers I would have. Have you filed bugs against the servers in question for the issues that you have seen? On 10 September 2016 at 00:23, Andreas Walz wrote: > Dear all,

Re: [TLS] Suspicious behaviour of TLS server implementations

nderstanding, any new field in the ClientHello would automatically break backward compatibility (at least with older compliant servers or unless everyone explicitly skips a MUST check in the interest of forward compatibility). ___ Andreas Walz Research Engineer

Re: [TLS] Suspicious behaviour of TLS server implementations

entations do reject such messages and send a "decode_error" alert. Do you see any argument why ignoring such trailing data would be acceptable (or even desirable)? Thanks again and Cheers, Andi Walz ___ Andreas Walz Research Engineer Institute

Re: [TLS] Suspicious behaviour of TLS server implementations

extending beyond the message boundary or contain an out-of-range length) MUST terminate the connection with a "decoding_error" alert." Cheers, Andi >>> Martin Thomson 09/21/16 9:25 AM >>> On 21 September 2016 at 17:21, Andreas Walz wrote: > Do you se

[TLS] Antw: Re: Suspicious behaviour of TLS server implementations

>>> Peter Gutmann 21.09.16 17.54 Uhr >>> > If you're writing a strict validating protocol parser than disconnecting in > this case is a valid response, but if it's software that will be used by > actual humans then failing a connect based on something like this makes no > sense. Wouldn't this

[TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations

>>> Peter Gutmann 22.09.16 7.00 Uhr >>> > Nope. There's a big difference between "I can't continue" and "I can > continue without any problems but don't want to". The example I gave of > "Couldn't connect to Amazon because no suitable encryption was available" > would be the error message to

Re: [TLS] TLS1.3 + PSK with multiple identities

discussion about this on the list, see thread "Suspicious behaviour of TLS server implementations". We are currently refining our study and in the process of writing a paper. I hopefully can give more details on results soon. Cheers, Andi _______ Andreas Wal

[TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?]

Dear all, bringing up this thread again In the course of studying the way TLS implementations treat the "version" (or "legacy_record_version") field in the record header, we were wondering (please excuse if we missed some arguments here from past discussions): (1) What is an implementat

Re: [TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?]

e. Otherwise, this field is given away for arbitrary and non-standardized (ab)use ... Thanks and Cheers, Andi ___ Andreas Walz Research Engineer Institute of reliable Embedded Systems and Communication Electronics (ivESK) Offenburg University of Applied Sciences,

Re: [TLS] FW: New Version Notification for draft-jay-tls-psk-identity-extension-02.txt

gt; Section 5.3: A "(" is missing in the diagram below "ServerHello" -> There are some more typos. Do you have a Git repository where I could post a pull request for those? I guess that would be more efficient than listing them here. Thanks and Cheers, Andi Walz

Re: [TLS] FW: New Version Notification for draft-jay-tls-psk-identity-extension-02.txt

ndard-compliant though and support any plan or effort that helps scaling (D)TLS down without sacrificing security. Thanks and Best Regards, Andi Walz ___ Andreas Walz Research Engineer Institute of reliable Embedded Systems and Communication Electronics (ivESK) Offe

[TLS] draft-jay-tls-omit-aead-explicit-nonce-extension

any interest in breathing new life into that draft? In our scenario (DTLS for a legacy industrial wireless communication system) every single byte counts. That is why we would strongly support reviving this draft... Thanks and Cheers, Andi Walz ___ Andreas Walz

[TLS] ChaCha20+Poly1305 cipher suites with truncted authentication tag?

Walz ___ Andreas Walz Research Engineer Institute of reliable Embedded Systems and Communication Electronics (ivESK) Offenburg University of Applied Sciences, 77652 Offenburg, Germany ___ TLS mailing list TLS@ietf.org

Re: [TLS] ChaCha20+Poly1305 cipher suites with truncted authentication tag?

e is consensus that there is no point in having ChaCha20+Poly1305 with truncated tags I'm fine with that. Maybe this would just rebut my assumption that there could be broader use for that. Cheers, Andi Walz >>> Hanno Böck 01/17/17 1:10 PM >>> On Tue, 17 Jan 201

[TLS] Truncated HMAC: what to do with the MAC key?

AC extension (as WolfSSL is implementing it). Is that correct? Thank you very much! Cheers _______ Andreas Walz Email: andreas.w...@hs-offenburg.de Institute of reliable Embedded Systems and Communication Electronics (ivESK) Homepage: http://ivesk.hs-offenburg.de/ U

[TLS] Antw: Re: Truncated HMAC: what to do with the MAC key?

pdf?__blob=publicationFile&v=1 >>> Dave Garrett 08.07.17 7.15 Uhr >>> On Saturday, July 08, 2017 12:38:18 am Peter Gutmann wrote: > Andreas Walz writes: > >different TLS implementations do not seem to agree on how to implement > >truncated HMAC > > It also says some