Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)
rfc-edi...@rfc-editor.org writes: >RFC 7919 > > Title: Negotiated Finite Field Diffie-Hellman Ephemeral > Parameters for Transport Layer Security (TLS) Does anyone have a test server running that implements this? Since I mention it in TLS-LTS, I'd like to do some interop testing on it to see if there's anything that needs to be mentioned in -LTS. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)
A new Request for Comments is now available in online RFC libraries. RFC 7919 Title: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) Author: D. Gillmor Status: Standards Track Stream: IETF Date: August 2016 Mailbox:d...@fifthhorseman.net Pages: 29 Characters: 61937 Updates:RFC 2246, RFC 4346, RFC 4492, RFC 5246 I-D Tag:draft-ietf-tls-negotiated-ff-dhe-10.txt URL:https://www.rfc-editor.org/info/rfc7919 DOI:http://dx.doi.org/10.17487/RFC7919 Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups. This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) extensions (RFC 4492). This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] RFC 7918 on Transport Layer Security (TLS) False Start
A new Request for Comments is now available in online RFC libraries. RFC 7918 Title: Transport Layer Security (TLS) False Start Author: A. Langley, N. Modadugu, B. Moeller Status: Informational Stream: IETF Date: August 2016 Mailbox:a...@google.com, nagen...@cs.stanford.edu, bmoel...@acm.org Pages: 11 Characters: 23825 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tls-falsestart-02.txt URL:https://www.rfc-editor.org/info/rfc7918 DOI:http://dx.doi.org/10.17487/RFC7918 This document specifies an optional behavior of Transport Layer Security (TLS) client implementations, dubbed "False Start". It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip. This document is a product of the Transport Layer Security Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA
Tony Arcieri wrote: > > It's also worth noting that BERserk is one of many such incidents of this > coming up in practice: > https://cryptosense.com/why-pkcs1v1-5-signature-should-also-be-put-out-of-our-misery/ With the PKCS#1 v1.5 signature verification operation, as described in PKCS#1 v2.0 (rfc2437, Oct-1998, Section 8.1.2) https://tools.ietf.org/html/rfc2437#section-8.1.2 it is *IMPOSSIBLE* to create an implementation with a bug such as BERserk, because there is (on purpose) *NO* ASN.1 decoding step defined for this signature verification. A useful specification that is almost 2 decades old does not protect from clueless implementors, however. Heartbleed is also not part of the underlying specification. Anyhow some very seriously broken code, for a completely useless feature (within TLS, not DTLS), was created and shipped into large parts of the installed base... -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead
On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote: > All, > > We've received a request for early IANA assignments for the 6 cipher > suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh > e-psk-aead/. Please respond before August 23rd if you have concerns > about early code point assignment for these cipher suites. I have previously raised an issue [0] on these ciphersuites. The same requirement was noted also by Peter Dettman as something special in [1]. However, there has been no reaction from the authors (now in CC). regards, Nikos [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ [1]. https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
