Martin Thomson | 24 Jul 20:21 2014
Picon

shibboleth and the nonce

(No, that's not a proposed prog-synth-death-polka band name.)

The arguments around the way that explicit/implicit nonces interact
with certification were, I thought, already exhausted.  So I'd like to
see if some points can be clarified:

As far as I am aware, there are no concrete concerns about implicit
nonces from a straight-up security perspective.  Is that right?

If the concerns are solely around the certification of crypto modules,
then we need more information to be able to make a rational decision
here.

If the static inputs are keys, and the per-record inputs are nonce +
ad + plaintext, I see no problem.

The previous response to suggestions that the nonce was a required
input was to have a counter produce the nonce input, with a matching
counter and validation in the module.

The new information yesterday was that David McGrew suggested that the
nonce needed to be arbitrary.  In that case, do we actually need the
input to be validated?  Does the certification process check that the
module produces different output for different nonces by starting
separate module instances with the same values for all other inputs
(keys, ad, and plaintext) then varying the input nonces?

I'm sure that there are other concerns, but it's hard for me to make
an assessment based on the information made available thus far.
(Continue reading)

internet-drafts | 23 Jul 00:12 2014
Picon

I-D Action: draft-ietf-tls-negotiated-ff-dhe-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           : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS
        Author          : Daniel Kahn Gillmor
	Filename        : draft-ietf-tls-negotiated-ff-dhe-00.txt
	Pages           : 19
	Date            : 2014-07-22

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 establishing
   a registry of DH parameters with known structure and a mechanism for
   peers to indicate 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-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:
(Continue reading)

internet-drafts | 22 Jul 14:17 2014
Picon

I-D Action: draft-ietf-tls-encrypt-then-mac-03.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           : Encrypt-then-MAC for TLS and DTLS
        Author          : Peter Gutmann
	Filename        : draft-ietf-tls-encrypt-then-mac-03.txt
	Pages           : 7
	Date            : 2014-07-22

Abstract:
   This document describes a means of negotiating the use of the
   encrypt-then-MAC security mechanism in place of TLS'/DTLS' existing
   MAC-then-encrypt one, which has been the subject of a number of
   security vulnerabilities over a period of many years.

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-encrypt-then-mac-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-encrypt-then-mac-03

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/
(Continue reading)

Sean Turner | 21 Jul 20:13 2014

wg github repo

In addition to uploading WG slides to the usual place (http://tools.ietf.org/agenda/90/) we’ve also
set up a github repo for the wg.  It is located here:

   https://github.com/tlswg

There’s a place for wg-materials:

   https://github.com/tlswg/wg-materials

The TLS 1.3 specification can also be found there:

  https://github.com/tlswg/tls13-spec

spt
Manuel Pégourié-Gonnard | 21 Jul 19:17 2014

DTLS HelloVerifyRequest.server_version

Hi,

Sorry if I'm just being dense and fail to understand something very
obvious, but I have trouble understanding how the server_version field
of HelloVerifyRequest should be handled, according to section 4.2.1 of
RFC 6347.

More precisely, I'm under the impression that the last paragraph of page
15 and the first of page 16 contain contradictory statements:

                      DTLS 1.2 server implementations SHOULD use DTLS
   version 1.0 regardless of the version of TLS that is expected to be
   negotiated.

                                          The server MUST use the same
   version number in the HelloVerifyRequest that it would use when
   sending a ServerHello.

It seems to me that if a server obeys the MUST of the second sentence,
it cannot obey the SHOULD of the first one (unless of course it never
negotiates DTLS 1.2, which I assume is not the intention of the RFC).

                DTLS 1.2 and 1.0 clients MUST use the version solely to
   indicate packet formatting (which is the same in both DTLS 1.2 and
   1.0) and not as part of version negotiation.  In particular, DTLS 1.2
   clients MUST NOT assume that because the server uses version 1.0 in
   the HelloVerifyRequest that the server is not DTLS 1.2 or that it
   will eventually negotiate DTLS 1.0 rather than DTLS 1.2.

                           Upon receipt of the ServerHello, the client
(Continue reading)

Phillip Hallam-Baker | 19 Jul 18:28 2014

Non-TLS opportunistic encryption

While at the Hope conference watching the 'HTTP must die' presentation
I had an idea that might or might not be useful.

People frequently propose use of opportunistic TLS with self-signed
credentials. This worries me for two reasons:

1) TLS is a huge standard with a lot of details that have to be got
right. It takes a lot of time and effort to implement and a lot of
memory to run. Constrained devices are going to find it very hard to
do TLS

2) One consequence of (1) is that opportunistic TLS risks weakening
the https infrastructure rather than improving the http
infrastructure. That is not a win as far as I am concerned.

So one proposal that is made is to drop the padlock icon when
non-credentialed self-signed certs or keys passed in band are in use.
This seems a very good approach to me but we still have the problem of
it being a 'thick stack'.

This is even more problematic when we consider the fact that most of
that 'thick stack' is actually involved in addressing issues that just
don't apply if we are not going to validate the end-entity-keys.

Self-signed certs are a reasonable way to exchange keys in a world
where the infrastructure has ubiquitous support for X.509 path math.
But why clutter up the client with the path math if we are not going
to check cert chains?

If we are going to insist on 'encryption everywhere' and accept
(Continue reading)

Sean Turner | 21 Jul 17:21 2014

tls 1.3: renegotiation

At the TLS interim meeting held on Sunday July 20th, 2014, there was consensus to remove renegotiation on
the assumption we will provide a rekeying facility of some form and client initated client
authentication.  This message serves to confirm that consensus.  Please indicate by July 25th, 2014
whether you disagree with this (and why).

spt
Sean Turner | 21 Jul 17:08 2014

Call for adoption: draft-bhargavan-tls-session-hash

At the TLS interim meeting held Sunday the 20th of July 2014, we discussed adopting the following draft:

http://datatracker.ietf.org/doc/draft-bhargavan-tls-session-hash/

There was consensus to adopt it with the stipulation that the Signaling Cipher Suite Value (SCSV) be
removed.  Please indicate whether you object to adoption (and why) by July 25, 2014.

spt

PS Stay tuned for an early code point assignment thread.
Sean Turner | 21 Jul 16:46 2014

adopted: draft-popov-tls-prohibiting-rc4-02

At the TLS interim held on 20140720, there wg consensus was re-confirmed to adopt
draft-popov-tls-prohibiting-rc4-02 .  This is consistent with the wg adoption call (http://www.ietf.org/mail-archive/web/tls/current/msg11932.html).

Andrei,

Please submit your individual draft as draft-ietf-tls-prohibiting-rc4-00.

spt
{for the chairs}
Joseph Salowey (jsalowey | 21 Jul 16:45 2014
Picon

Removing support for custom unnamed DIffie-Hellman groups

At the interim there was support for removing support for custom unnamed Diffie-Hellman groups from TLS
1.3.  If you have an objection please respond on the list by July 25, 2014.

Thanks,

Joe 
[For the chairs] 
Watson Ladd | 21 Jul 16:42 2014
Picon

Re: [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves

On Sun, Jul 20, 2014 at 8:56 PM, Benjamin Black <b <at> b3k.us> wrote:
> On Sat, Jul 19, 2014 at 9:50 PM, Watson Ladd <watsonbladd <at> gmail.com> wrote:
>>
>> On Sat, Jul 19, 2014 at 4:09 PM, Benjamin Black <b <at> b3k.us> wrote:
>> > "This stems from the fact that in some specific cases an algorithm and a
>> > curve are closely linked, with the two in some sense being carefully
>> > co-designed to gain security and performance."
>> >
>> > I am aware of claims to this effect, but I have seen no evidence of
>> > meaningful security or performance gains that would be seen in practical
>> > deployments in TLS. Similar claims have been made about the dramatic
>> > performance gains from certain curve forms, but the MSR research that
>> > produced the NUMS curves shows only slight performance advantages for
>> > those
>> > forms and only at low security levels. The ECCLib implementations
>> > support
>> > the conclusion that there is little benefit. Please provide specific
>> > supporting documentation for claims of significant, not incremental,
>> > performance or security gains for TLS from this.
>>
>> http://bench.cr.yp.to/
>>
>> Of course, when it comes to TLS, the two round trips cost far more,
>> but when we have 1-RTT the exponentiations become far
>> more critical for performance. Furthermore, CPU is not free, while a
>> server can do other things while it waits.
>>
>
> If TLS 1.2 is a guide, we are 5 years from widespread TLS 1.3 deployment. I
> suggest 2 round trips is a more realistic expectation here.
(Continue reading)


Gmane