Yoav Nir | 15 Dec 23:29 2014
Picon

RFC4492bis - Removing ECDH

Hi.

I’ve created pulll request #2 for removing references to ECDH (static elliptic curve key) key exchange and ciphersuites.


Yes, there are other suggestions there, but I’d like to take them one by one.

Let me know what you think

Yoav

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Sean Turner | 15 Dec 14:25 2014

Re: [tls13-spec] Pre submit cleanup (#84)

On Oct 27, 2014, at 12:51, Rich Salz <notifications <at> github.com> wrote:

> Should remove Dierks. 
> 
> —
> Reply to this email directly or view it on GitHub.
> 

Rich suggested that Tim’s name be removed from the front of the draft and have Tim be appropriately
acknowledge for work on earlier version of the protocol later in the draft.  I asked whether there were any
objections at the Hawaii interim to doing this and there were none.  Joe and I think it’s time this change
be made so EKR - you should feel free to make these changes when you get a chance, or somebody can submit a PR.

spt
Henrick Hellström | 10 Dec 11:32 2014
Picon

Trusted CA Keys

Is anyone using the trusted_ca_keys(3) extension for any kind of public 
services?

The security considerations seem a bit discouraging, and almost invites 
usage of the extension for putting confidential proprietary identifiers 
in the cert_sha1_hash field.
Brian Smith | 10 Dec 07:33 2014

False Start, DHE key exchange, and the Negotiated FF-DHE extension

* The vast majority of servers that pick DHE key exchange, in Firefox
at least, are using 1024-bit *or smaller* DHE keys, and/or keys with
other problems.

* It may be the case that the server is configured with good ECDHE
parameters and DHE parameters that aren't as strong as the ECDHE
parameters. In fact, most servers that support both ECDHE and DHE key
exchange seem to be configured like this: P-256 for ECDHE, and
1024-bit keys for DHE. (Note that the key size may not be the only
issue with the DHE parameters, and that the possible problems with DH
parameters other than key size are difficult and/or very expensive to
check.) An attacker can modify the ClientHello to trick such a server
into choosing its weak DHE parameters instead of its strong ECDHE
parameters.

* The Negotiated FF-DHE draft mechanism is specified in such a way
that the server's signature on DHParams does not cover the client or
server FF-DHE extensions, because the definition of DHParams was not
modified to cover them. This is unfortunate, because it means that
these parameters, and thus the entire DHE exchange, cannot be fully
validated until the peer's Finished message is validated. In
particular, this means that the FF-DHE mechanism, as currently
designed, is not useful for enhancing the security of False Start
handshakes that use DHE key exchange.

* Firefox and Chrome (IIUC) are both removing support for DHE_DSS key
exchange, due to non-use by servers and/or too-small key DSS key sizes
(almost always 1024 bits). Obviously, there are other implementations
to consider, but I think the reasoning behind the Firefox and Chrome
decisions likely applies to most/all other implementations that would
do False Start.

Because of the above issues, the False Start draft should be changed
to remove DHE_RSA and DHE_DSS from the list of recommended key
exchange algorithms, leaving only ECDHE_RSA and ECDHE_ECDSA in the
list.

Cheers,
Brian
Brian Smith | 10 Dec 07:12 2014

False Start and TLS 1.3+

1. TLS 1.3 will have its own 1-RTT mechanism, so it makes less (no?)
sense do do False Start for TLS 1.3.

2. During the development and testing of TLS 1.3, it is far from clear
that a TLS 1.3 handshake will be as secure as a TLS 1.2 handshake. It
seems likely, in fact, that for some handshakes, due to implementation
bugs, and/or problems in new parts of the protocol, that TLS 1.3 could
be a security downgrade from TLS 1.2, at least until TLS 1.3 gets its
RFC number.

3. During the development of TLS 1.3, my understanding is that an
extension will be used to negotiate which draft of TLS 1.3 is being
spoken. This extension would only be safe for False Start if every
draft were equally secure, which is unlikely.

Because of these reasons, the False Start draft should be updated to
say that False Start MUST NOT be used for TLS 1.3 and later.

Cheers,
Brian
internet-drafts | 10 Dec 00:56 2014
Picon

I-D Action: draft-ietf-tls-sslv3-diediedie-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : Deprecating Secure Sockets Layer Version 3.0
        Authors         : Richard Barnes
                          Martin Thomson
                          Alfredo Pironti
                          Adam Langley
	Filename        : draft-ietf-tls-sslv3-diediedie-00.txt
	Pages           : 6
	Date            : 2014-12-02

Abstract:
   Secure Sockets Layer version 3.0 (SSLv3) [RFC6101] is no longer
   secure.  This document requires that SSLv3 not be used.  The
   replacement versions, in particular Transport Layer Security (TLS)
   1.2 [RFC5246], are considerably more secure and capable protocols.

   This document updates the backward compatibility sections of the TLS
   RFCs to prohibit fallback to SSLv3.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Yoav Nir | 8 Dec 15:31 2014
Picon

RFC4492bis - merging errata

Hi folks

I’ve created PR #1 for merging the errata([1]) for RFC 4492 ([2]).

Let me know if this is controversial


Yoav


_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
internet-drafts | 5 Dec 19:41 2014
Picon

I-D Action: draft-ietf-tls-negotiated-ff-dhe-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS
        Author          : Daniel Kahn Gillmor
	Filename        : draft-ietf-tls-negotiated-ff-dhe-04.txt
	Pages           : 22
	Date            : 2014-12-05

Abstract:
   Traditional finite-field-based Diffie-Hellman (DH) key exchange
   during the 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 "EC Named Curve Registry" to establish common
   finite-field DH parameters with known structure and a mechanism for
   peers to negotiate support for these groups.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Yuhong Bao | 3 Dec 03:59 2014
Picon

Combine TLS 1.0/1.1 into a single RFC

Given that TLS 1.0 is not dying soon, I wonder if it would make sense to combine TLS 1.0 and 1.1 into one RFC,
given the minor changes involving the IV. This would include changing the mandatory to implement cipher
suite for TLS 1.0 to TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Yuhong Bao 		 	   		  
internet-drafts | 2 Dec 14:26 2014
Picon

I-D Action: draft-ietf-tls-rfc4492bis-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2
and Earlier
        Author          : Yoav Nir
	Filename        : draft-ietf-tls-rfc4492bis-00.txt
	Pages           : 31
	Date            : 2014-12-02

Abstract:
   This document describes key exchange algorithms based on Elliptic
   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
   protocol.  In particular, it specifies the use of Elliptic Curve
   Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of
   Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
   authentication mechanism.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Hannes Tschofenig | 28 Nov 20:36 2014
Picon
Picon

TLS False Start

Hi Bodo,
Hi all,

I read through <draft-bmoeller-tls-falsestart-01>. The document is well
written but I have a few questions.

There are various conditions specified when the TLS False Start
mechanism is fit for use. I believe there is room for improvement
regarding the way how these conditions are formulated. At the moment,
they are more written as examples rather than a list of security
properties.

I am worried that many of the provided examples will be outdated fairly
soon as algorithms continuously evolve.

For example, you say that AES-GCM is OK. You cite the key length and I
guess you are also including the current state of security analysis of
the given cipher in that consideration. Would it be OK to use AES-CCM
with False Start? I think so.

Then, you list a couple of key exchange methods (DHE_RSA, ECDHE_RSA,
DHE_DSS, ECDHE_ECDSA), which you consider being fit for TLS False Start.
You indicate that an ephemeral DH exchange is need and I was wondering
why this is the case? Why isn't a "normal" DH not acceptable?

Would a ciphersuite like TLS_PSK_WITH_AES_128_CCM_8 be acceptable since
it does not use a public key based ciphersuite and it also does not use
an ephemeral Diffie-Hellman exchange.

Finally, you list "client certificate types". As someone who is
interested in the PSK case I am wondering whether you would consider PSK
ciphersuites as acceptable as well. With the indicated criteria it is a
bit hard to tell.

Ciao
Hannes

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls

Gmane