Daniel Kahn Gillmor | 22 Apr 06:07 2014
Picon

Re: RFC 4492 and HSM

On 04/21/2014 09:00 PM, Watson Ladd wrote:

> RFC 4492 specifies an ECDSA signature of the server's curve parameters
> and ephemeral point, but not any fresh data. As a result the ephemeral
> exponent is equal in sensitivity to the long-term exponent of the
> ECDSA key, forcing an HSM to protect both, and thus do three
> exponentiations per connection.

It looks to me like RFC 4492 specifies that the data signed includes
both the ClientHello.random and the ServerHello.random:

 https://tools.ietf.org/html/rfc4492#page-20

fwiw the traditional discrete-log-based DHE key exchange includes the
same data in the signature:

  https://tools.ietf.org/html/rfc5246#page-52

I would consider this "fresh data", particularly the inclusion of the
ClientHello.random.

I agree that if there were no fresh data, then every single ephemeral
key used would be equivalent to the server's static public key for reuse
by an active attacker, which seems like it would a problem (especially
given any attacker's ability to trivially harvest new signatures over
novel ephemeral keys).

> If an HSM has limited signing power compared to the CPU of the machine
> it is attached to this is a real limitation. An extra layer of
> indirection, in which a time limited key is signed by the certificate,
(Continue reading)

Watson Ladd | 22 Apr 03:00 2014
Picon

RFC 4492 and HSM

Dear all,
RFC 4492 specifies an ECDSA signature of the server's curve parameters
and ephemeral point, but not any fresh data. As a result the ephemeral
exponent is equal in sensitivity to the long-term exponent of the
ECDSA key, forcing an HSM to protect both, and thus do three
exponentiations per connection.

If an HSM has limited signing power compared to the CPU of the machine
it is attached to this is a real limitation. An extra layer of
indirection, in which a time limited key is signed by the certificate,
avoids this issue, but is not currently supported if I'm reading
everything correctly. Triple-DH handshakes partially mitigate this
issue, reducing the online impact to one exponentiation per
connection.

If this wrinkle doesn't get ironed out I'm not terribly unhappy. But
if we are going to do major surgery on the PRF and related things, the
ECDHE handshake is exposed anyway.

Sincerely,
Watson Ladd
The IESG | 21 Apr 17:40 2014
Picon

Protocol Action: 'Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension' to Proposed Standard (draft-ietf-tls-applayerprotoneg-05.txt)

The IESG has approved the following document:
- 'Transport Layer Security (TLS) Application Layer Protocol Negotiation
   Extension'
  (draft-ietf-tls-applayerprotoneg-05.txt) as Proposed Standard

This document is the product of the Transport Layer Security Working
Group.

The IESG contact persons are Stephen Farrell and Kathleen Moriarty.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/

Technical Summary

This document describes a Transport Layer Security (TLS) extension
for application layer protocol negotiation within the TLS handshake.
For instances in which the TLS connection is established over a well
known TCP/IP port not associated with the desired application layer
protocol, this extension allows the application layer to negotiate
which protocol will be used within the TLS session.

Working Group Summary

The main point of controversy with this document was on encryption
of the extension. The working group decided a cleartext extension
with the future general facility to encrypt extensions in TLS 1.3 was
preferable to an extension specific encryption mechanism for ALPN.

Document Quality
(Continue reading)

Henrick Hellström | 20 Apr 10:47 2014
Picon

Re: Kill Finished (and other tricks for hardware)

On 2014-04-18 17:39, Watson Ladd wrote:
> On Fri, Apr 18, 2014 at 8:16 AM, Henrick Hellström <henrick <at> streamsec.se> wrote:
>> On 2014-04-18 07:59, Michael D'Errico wrote:
>>>
>>> This is a much weaker failure indication than checking the Finished
>>> messages, so I'd prefer to keep them.  Can you think of an alternate
>>> construction for the Finished message that doesn't use the PRF?
>>
>>
>> Indeed. The client (being the last peer of the connection to send a random
>> handshake message, and being in a position to pick the pre_master_secret)
>> will have a quadratically improved chance of picking a specific
>> master_secret

Please note that this relevant in the context of removing the Finished 
messages and including the handshake hash in the KDF step, because of 
the following questions:

   #1. How easy is it for an attacker to pick one specific master_secret 
as the output of a handshake?
   #2. How easy is it for an attacker to pick any master_secret, that 
happens to produce the correct finished messages and a partially chosen 
key block (e.g. with only one write key chosen) when the handshake hash 
is not included in the KDF step?
   #3. How easy is it for an attacker to pick any master_secret, that 
happens to produce a partially chosen key block (e.g. with only one 
write key chosen) when the handshake hash is included in the KDF step?

(I am not elaborating on exactly what kind of practical attacks would 
become possible if the attacker picks a partially correct master_secret. 
(Continue reading)

Watson Ladd | 19 Apr 08:03 2014
Picon

RC4 depreciation path (Re: Deprecating more (DSA?))

On Thu, Apr 17, 2014 at 9:15 AM, Brian Sniffen <bsniffen <at> akamai.com> wrote:
> Alyssa Rowan <akr <at> akr.io> writes:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> It looks like RC4 is rapidly heading for the chopping block, with
>> basically unanimous consensus. Good.
>
> Agreed, mod Martin's proposal that I understand to ask for a reasonable
> path by which we strongly deprecate RC4 on clients, then after a client
> generation ban RC4 on clients and deprecate for servers.

I don't think this is the correct path. I think what we should do is
have clients and servers both prefer other options (in all TLS
versions), then once that change is made, ban it entirely. Deprecation
on one side won't affect the other side if there isn't an alternative
mandated. (Right now RC4 only servers are keeping RC4 alive).

This first step has already happened in the web context on modern
browsers. What we need is to make the server side step happen, and
then think about removal in the second step.

Sadly, our ability to force upgrades is very limited.

How long a client generation were you thinking? Because I could see
cryptanalysis speeding up: RC4 has been neglected for about 12 years
after WEP, but the new techniques of massive brute force coupled with
some good idea might bear fruit sooner than expected.

(Continue reading)

Michael StJohns | 18 Apr 17:05 2014

PRF Negotiation - Finished "gotcha"

As I was working through the "finished" message email I just sent, I 
realized something about PRF negotiation.   The client, when it sends a 
ClientHello, doesn't necessarily know which PRF it will be using 
(assuming there are multiple PRFs defined in the offered cipher suites) 
until it gets the ServerHello back.  I think that means that the client 
either needs to keep a copy of the ClientHello around (or the data to 
rebuild it), or needs to keep multiple HASH states - one for each PRF 
algorithm.

It may be useful to add a paragraph on PRF negotiation implications that 
provides this guidance.

Mike
Watson Ladd | 18 Apr 16:58 2014
Picon

Fwd: Kill Finished (and other tricks for hardware)

Dear all:
I screwed up my reply and Nicos argued it needed to be sent to the list.

On Thu, Apr 17, 2014 at 7:23 PM, Nico Williams <nico <at> cryptonector.com> wrote:
> On Thu, Apr 17, 2014 at 8:35 PM, Watson Ladd <watsonbladd <at> gmail.com> wrote:
>> On Thu, Apr 17, 2014 at 6:10 PM, Nico Williams <nico <at> cryptonector.com> wrote:
>>> This would require updating the tls-unique channel binding (which the
>>> resumption bug doesn't: just fix resumption).
>>
>> You have a master key: do another extraction from it. I don't see this
>> as unsolvable.
>
> I was pointing out a fact.  Clearly it's solvable.
>
>>> Also, are you proposing to have no message which demonstrates
>>> possession of the shared master secret immediately after being able to
>>> compute it?
>>
>> Yes. Key confirmations are useful in extremely limited circumstances.
>
> Are key confirmations cargo cult?  It depends:
>
> If one is doing channel binding then a channel binding confirmation
> -which might look much the same as key confirmation- is needed.  The
> reason is that the point of CB is to leave encryption to the
> lower-layer channel, but only if there was no MITM there.

Is channel binding really necessary in TLS? I agree key extractors
are, but I think the cases where TLS is layered on encrypted channels
are pretty rare. Of course if TCPcrypt becomes more common this will
(Continue reading)

Watson Ladd | 18 Apr 03:03 2014
Picon

Kill Finished (and other tricks for hardware)

Dear all,

Recently Michael St. Thomas pointed out the PRF is painful in
hardware. It's painful in software if you do monadic tricks to ensure
keys are only encrypted with and never sent over the wire or process
isolation to ensure that they are never read. So I'll make a radical
proposal, and it will get pared down to something acceptable over
time.

So I propose the following changes: Client IV starts at 0 and proceeds
through the even numbers, Server IV from 1 and proceeds through the
odd numbers.

Finished dies. Instead we hash the entire handshake, certs and all
into the master secret. This has the side effect of making life for
cryptographers a lot nicer. I've not figured out resumption quite yet:
maybe this is a problem there. I've also probably missed some other
outputs that need munging or replacements.

This way the PRF is only used to generate keys, so it can be marked at
such. There aren't any security implications: we've replaced finished
with the master secret hashing, so the only way to get two identical
master secrets is from identical exchanges.

Sincerely,
Watson Ladd
Erik Nygren | 18 Apr 01:05 2014

Re: About encrypting SNI

On Thu, Apr 17, 2014 at 1:00 PM, Martin Thomson <martin.thomson <at> gmail.com> wrote:
On 17 April 2014 08:05, Erik Nygren <erik+ietf <at> nygren.org> wrote:
> 4) Send a long byte-string key label which allows the server to pack in
> enough information to allow it to be time-variant (eg, a timestamp plus an
> encrypted version of the timestamp and more detailed routing information)

Isn't that what draft-ekr-tls-new-flows effectively proposes?

Exactly, hence my proposal to include that in a DNS Service Binding record. 
The concern raised was that this could be used by a passive attacker
to further identify the hostname the client was connecting to.
By preference would be to take this approach but provide some guidance
on a way to help raise the bar.  For example, constructing this label with
something like:

    { timestamp, label_key_vers , AES(label_key, timestamp || SNI_routing_identifier || handshake_keyversion ) }

would reduce some of these attacks over just having a static value in the label (which might
degenerate down to something with a static 1:1 identifier with the SNI which would some of the
point of encrypting the SNI in the first place).

          Erik


_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Salz, Rich | 17 Apr 23:58 2014

Incorporate by reference

There are several TLS-related RFC’s that we probably want to roll up into TLS 1.3.  One thing we should consider is to incorporate them by reference.  For example, have a section that says

 

      The TLS padding specification, RFC nnnn, is to be considered part of this document and is incorporated by reference, with the following changes:

1.       …. Whatever… if there are any.

 

Be more explicit than just an entry in the ‘normative reference’ list.  And it gives us a chance to explicitly list errata, exceptions, etc.

 

There cases where this makes sense, and cases (encrypt then mac) where it doesn’t.     But I think it’s a worthwhile tool to have in the editor’s toolbox.

 

-- 

Principal Security Engineer

Akamai Technology

Cambridge, MA

 

 

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
internet-drafts | 17 Apr 23:34 2014
Picon

I-D Action: draft-ietf-tls-tls13-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           : The Transport Layer Security (TLS) Protocol Version 1.3
        Authors         : Tim Dierks
                          Eric Rescorla
	Filename        : draft-ietf-tls-tls13-00.txt
	Pages           : 102
	Date            : 2014-04-17

Abstract:
   This document specifies Version 1.3 of the Transport Layer Security
   (TLS) protocol.  The TLS protocol provides communications security
   over the Internet.  The protocol allows client/server applications to
   communicate in a way that is designed to prevent eavesdropping,
   tampering, or message forgery.

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-tls13-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/

Gmane