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

David-Sarah Hopwood <> Thu, 12 November 2009 05:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C0AA3A6A1C for <>; Wed, 11 Nov 2009 21:07:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.682
X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s67bV8RYkgcw for <>; Wed, 11 Nov 2009 21:07:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 517A53A68E6 for <>; Wed, 11 Nov 2009 21:07:14 -0800 (PST)
Received: by with SMTP id 9so472651eyd.51 for <>; Wed, 11 Nov 2009 21:07:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=7xM0hfG7jU1dSafblzxxxnMeWwHrUvminPHwIILFGfI=; b=tgkuZEH+UpkVSyQxUBK04qUcUfIuGeXp2rQObtEEcD5FtX3+CNRyhnoPV7GF5x/uem /uXv9yfOJxglFpgxGdxvXokvIxu+6mJmqoRiHwkMZ/uoLCE45L+yn4U27IKr1eDMJ+Pu Dcwvjq/STCQy7m4fvrSyUtDIsQraE2taMYnhk=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=MNWnjeGufl/nWHKIArKgx7jmfmm7n+GRMhN7sKiTAQlqaK2Fhz+n8B8Jb8boeYGbyt zOcPSqqplBVcCUhIdPSEq+sPL5Jsq4VKUAw20X7MOJ38J0Cvyuz806ttTuR0XUHx5F0Q YwGznlITNj4Q2nQF1mk/4L7W4PT+mMYQpgNrk=
Received: by with SMTP id 7mr7084244ebi.88.1258002459672; Wed, 11 Nov 2009 21:07:39 -0800 (PST)
Received: from ? ( []) by with ESMTPS id 10sm2256474eyd.47.2009. (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Nov 2009 21:07:39 -0800 (PST)
Sender: David-Sarah Hopwood <>
Message-ID: <>
Date: Thu, 12 Nov 2009 05:07:27 +0000
From: David-Sarah Hopwood <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv: Gecko/20070326 Thunderbird/ Mnenhy/
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------enigFC6D41FE075A87423CFB2CFC"
Subject: Re: [TLS] Comments on draft-solinas-tls-additional-prf-input
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Nov 2009 05:07:20 -0000

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.
> 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. 
> 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.
>    The mechanism described here has several desirable features which may
>    prove useful beyond the requirements of the US Government
>    applications.  It is easy to implement, and using it adds little to
>    the overall computation of the TLS handshake.  Further,
>    interoperability is preserved between clients that implement the
>    extension and servers that do not, and between clients that do not
>    implement the extension and servers that do.
> These really aren't generically desirable features, since they
> just say "this doesn't do any damage".  I guess that's desirable,
> but the relevant question is why one would want to do this at all.

I agree. The gist of any discussion of rationale seems to be basically:
"The U.S. Government has these special requirements that you wouldn't
understand. Since they're a government, they needn't explain themselves,
and we're not going to explain either."

One possible reason why you might want to cause a handshake failure
for clients and servers that fail to agree on the 'additional input',
is to avoid cross-protocol attacks, i.e. to prevent a session that
is supposed to be using one protocol from being misinterpreted as using
another. I'm not convinced that this extension is the simplest or most
effective way of doing that, though.

In the descriptions of 'OtherInfo' in
it seems that one intended usage is to prevent confusion about which
identities are participating in the key exchange (for example "At a
minimum, PartyUInfo shall include ID_U, the identifier of party U.",
on PDF page 46). In TLS that's unnecessary because any certificates
are included in the Finished hashes.

David-Sarah Hopwood  ⚥