Re: [TLS] Comments on draft-solinas-tls-additional-prf-input

Nicolas Williams <Nicolas.Williams@sun.com> Fri, 13 November 2009 17:43 UTC

Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A5C3A68C1 for <tls@core3.amsl.com>; Fri, 13 Nov 2009 09:43:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.02
X-Spam-Level:
X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlOl56kj5Ftj for <tls@core3.amsl.com>; Fri, 13 Nov 2009 09:43:19 -0800 (PST)
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 43FD13A6900 for <tls@ietf.org>; Fri, 13 Nov 2009 09:43:19 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nADHhnag024332 for <tls@ietf.org>; Fri, 13 Nov 2009 17:43:49 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nADHhmpP037381 for <tls@ietf.org>; Fri, 13 Nov 2009 10:43:48 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nADHWEIV019188; Fri, 13 Nov 2009 11:32:14 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nADHWExn019187; Fri, 13 Nov 2009 11:32:14 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Fri, 13 Nov 2009 11:32:14 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Eric Rescorla <ekr@networkresonance.com>
Message-ID: <20091113173214.GW1105@Sun.COM>
References: <20091111121708.EF62069EDB2@kilo.networkresonance.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20091111121708.EF62069EDB2@kilo.networkresonance.com>
User-Agent: Mutt/1.5.7i
Cc: draft-solinas-tls-additional-prf-input@tools.ietf.org, tls@ietf.org
Subject: Re: [TLS] Comments on draft-solinas-tls-additional-prf-input
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2009 17:43:20 -0000

On Wed, Nov 11, 2009 at 01:17:08PM +0100, Eric Rescorla wrote:
> Despite not being clear on what this is for, I don't have a problem
> with there being a code point assigned for this extension for USG use. 
> However, I don't think that some of the proposed uses are in
> fact appropriate and would like to see the document revised accordingly.
> 
> In particular, there are two potential things one might be trying
> to do here:
> 
> 1. Add additional randomness into the PRF.
> 2. Add structured, meaningful data into the PRF.

3. Add channel binding to other channels (for TLS, outside
   re-negotiation, this is extremely unlikely; no one is likely to care
   about TLS-to-IPsec channel binding for many years to com)

4. Provide integrity protection to application-layer negotiations that
   precede the TLS handshake.  Think of the "StartTLS" pattern in a
   large variety of protocols, including LDAP and HTTP (as opposed ldaps
   and https), where one might want to protect any pre-starttls
   negotiations (possibly by hashing pre-starttls messages and using
   them as the additional input).

5. Prove that out-of-band data (other than the type described in (4)) is
   the same on the client and server sides.

There may be others.

Examples of (3) and (4) exist.  Example of (3): SCRAM uses channel
binding.  Example of (4): SASL/GS2 uses the GSS-API channel binding
facility to protect data sent outside GSS-API context tokens.  Another
example of (4): a recent addition to OpenSolaris, a remote audit
protocol, uses the GSS-API channel binding facility to protect
application protocol version negotiation.

(3) may well be useless in TLS, outside the context of re-negotiation
anyways (where your fix is, effectively, to add a non-generic channel
binding from the inner to the outer connection).

(4) is, IMO, incredibly useful.  Paul seemed to misunderstand me the
other day and cut me off before I could explain that a channel binding
facility is not _only_ about channel binding, that there are uses for
such a thing that are not actually channel binding.

I have no examples of (5).  In very specific cases it may be useful.
(5) could also be used as a way to add a PSK-like component to TLS, but
one would have to be careful about how to identify a key for that.

> AFAICT, the first of these is useless but harmless: useless because
> the security guarantees of TLS require only uniqueness of the 
> Random values, not unpredictability, and 28 bytes is far more than
> required to provide a statistical guaranteee of uniqueness; harmless
> because the PRF can easily absorb additional new data, even if it
> is completely nonrandom. 

Agreed.

> The second, however, is a backdoor method of extending TLS and the
> semantics are completely different: in order to be useful, the
> data in the extension must be processed and potentially checked
> by the other side. Several mechanisms for extending TLS already
> exist (TLS Extensions and then the TLS Supplemental Data
> message) and should not add yet another generic mechanism 
> here.

You might argue that (4) is like (2), but then you'd also be saying that
the StartTLS pattern is a "backdoor method of extending TLS".  One might
see StartTLS as such a thing, but that ship has sailed.  I think (4) is
reason enough to have this feature in TLS.

You might argue that (3) will be useless (as I explained).  And you
might argue that (5) is dangerous or undesirable.  Even if we all were
to agree about (3) and (5), we'd still have (4).

> I don't have a problem with an opaque field here, since that's
> really just a private code point assignment. But having it
> have actual semantics leaks into TLS and I do object to that.

I don't agree.  See above.

I do, however, have comments on the mechanics of this extension, but
I'll leave those for another day.

> S 1.1.
>    Several recommendations for key derivation call for the concatenation
>    of additional information fields into the key derivation function
>    when producing a shared key.  For example, the specification of
>    Alternative 1 in NIST Special Publication 800-56A ([SP800-56A]) calls
>    for the inclusion of "OtherInfo" fields.  In this case, OtherInfo
>    contains the concatenation of a variety of mandatory and optional
>    sub-fields.  The extension described in this document provides a
>    simple mechanism both for supplying the public information to the
>    peer and for the inclusion of the information in the key derivation.
>    Many other application environments require or allow similar fields.
> 
> This actually seems extremely dangerous. AFAICT the point of these
> OtherInfo fields is that they are explicitly bound into the PRF
> on both sides. In order to be useful (as opposed to formally present),
> OtherInfo needs to be explicitly produced/verified by each side.
> This needs to be removed.

Agreed.

Nico
--