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

-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) Offenburg

[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?

s 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 <ha...@hboeck.de> 01/17/17 1:10 PM >>> On Tue, 17 Jan 2017 13:03:35 +01

[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

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

and Cheers >>> Martin Thomson <martin.thom...@gmail.com> 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, Andre

Re: [TLS] Suspicious behaviour of TLS server implementations

ot;decode_error" alert. Thus, to my understanding, 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). ___

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

Re: [TLS] Suspicious behaviour of TLS server implementations

nding beyond the message boundary or contain an out-of-range length) MUST terminate the connection with a "decoding_error" alert." Cheers, Andi >>> Martin Thomson <martin.thom...@gmail.com> 09/21/16 9:25 AM >>> On 21 September 2016 at 17:21, Andreas Wal

[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

Re: [TLS] Suspicious behaviour of TLS server implementations

ntations 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 of r

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

t one. 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

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

col version values, e.g. 0x.] Thanks and Cheers, Andi _______ Andreas Walz Research Engineer Institute of reliable Embedded Systems and Communication Electronics (ivESK) Offenburg University of Applied Sciences, 77652 Offenburg, Germany >>> Benjamin Ka

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

: 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 ___

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

pdf?__blob=publicationFile=1 >>> Dave Garrett <davemgarr...@gmail.com> 08.07.17 7.15 Uhr >>> On Saturday, July 08, 2017 12:38:18 am Peter Gutmann wrote: > Andreas Walz <andreas.w...@hs-offenburg.de> writes: > >different TLS implementations do not seem to agree on how

[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/

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: