Subject: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 Oct 2009 11:17:58 -0700

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>	Title		: Additional PRF Inputs for TLS
>
>	Author(s)	: J. Solinas, P. Hoffman
>	Filename	: draft-solinas-tls-additional-prf-input-00.txt
>	Pages		: 6
>	Date		: 2009-10-5
>	
>This document describes a mechanism for using additional PRF inputs
>   with Transport Layer Security (TLS) and Datagram TLS (DTLS).
>
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-solinas-tls-additional-prf-input-00.txt

Greetings again. We would like to hear input on this draft from the TLS community. The basic idea is an extension that would allow the two parties to give additional information that is directly mixed into the master secret through the PRF.

--Paul Hoffman, Director
--VPN Consortium

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 Oct 2009 15:34:04 +0200

Paul Hoffman <[email-masked]> writes:

> Greetings again. We would like to hear input on this draft from the
> TLS community. The basic idea is an extension that would allow the two
> parties to give additional information that is directly mixed into the
> master secret through the PRF.

The document seems fine to me.

As far as I can tell, any implementation (including mine) of
draft-rescorla-tls-opaque-prf-input-00.txt would be compatible with
draft-solinas-tls-additional-prf-input-00.txt, and that is good.

The two last examples in section 1.1 doesn't appear fully baked to me.
Quoting:

  TLS servers may arrange for their clients to provide authentication
  data early in the protocol (such as an HMAC value computed over a
  fresh random value using a shared secret as the key) in order to
  authenticate the client as a member of a private network or as an
  additional means of mitigating the impact of a denial-of-service
  attack.
				
  Implementors may want to provide a mechanism for relaying identity and
  version information similar to the "Vendor ID Payload" used in ISAKMP
  [RFC2408].

If these use-cases are intended to be realistic use-cases of the
extension (which doesn't seem clear to me), I believe the document needs
more work: it should suggest a structure of the PRF data so that servers
will understand what type of data the client sent.  Compare for example
how RFC 5077 suggests a format.  The document could even go further and
mandate a particular format, which would make the use-cases more likely
to interoperate, such as:

     enum {
         entropy(0), (65535)
     } AdditionalPRFInputType;

     struct {
         AdditionalPRFInputType type;
         opaque value<0..2^16-1>;
     } AdditionalPRFInput;

     AdditionalPRFInput prfinputs<2..2^16-2>;

The AdditionalPRFInputType could be a FCFS registry.  The intention with
the "entropy" field is that it should contain random data with no
intended meaning, which appears to be the typical use-case.  Other types
can be allocated to signal the two use-cases in the example if/when
needed.

Alternatively, and considering the complexities in my proposed change, I
would suggest that you remove other use cases than the one to provide
additional entropy to the MS key computation and say that there is only
one intended use-case for this extension.  If other use-cases of the
extension are important, they can be described in separate documents.

Thanks,
/Simon

---

From: Michael Gray <[email-masked]>
Date: Wed, 7 Oct 2009 09:35:52 +1000

Paul Hoffman <[email-masked]> wrote:

> TLS community. The basic idea is an extension that would allow the
> two parties to give additional information that is directly mixed
> into the master secret through the PRF.
>
> --Paul Hoffman, Director
> --VPN Consortium

Comparing this with draft-rescorla-tls-extended-random-02.txt I see the
requirement for the size of Server response is missing and thus undefined.
>From 3.1 in the above we have:

   If the server wishes to use the extended randomness feature, it MUST
   send its own "extended_random" extension with an
   extended_random_value equal in length to the client's
   extended_random_value

Additionally, I think some limitation of the size/amount of data that can
be requested from a server is needed as large sizes could pose an attack on
a server by exhausting the entropy pool and/or causing server performance
degradation.  Our prototype implementation allows servers to ignore or
respond with error, depending on configuration, requests from clients that
are larger than 256 octets.

Mick Gray
IBM

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 6 Oct 2009 18:40:43 -0500

> to interoperate, such as:

This is effectively a channel binding input to TLS.  Uses of a channel
binding input are not limited to channel binding (which is not likely to
be useful to TLS, even though channel binding to IPsec would clearly be
feasible).

For example, in SCRAM/GS2 we use GSS-API channel binding in the
construction of a SASL mechanism to protect cleartext sent outside the
GSS-API mechanism's tokens.  A secure audit protocol in OpenSolaris uses
GSS-API channel bindings to protect early application protocol version
negotiation.  And so on.

I think this is likely to be particularly useful to StartTLS-type
applications, as a way of integrity-protecting early application
protocol version negotiation.  I suspect this extension will also be
particularly useful to DTLS applications, for similar reasons.

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 6 Oct 2009 17:16:38 -0700

>requirement for the size of Server response is missing and thus undefined.

Correct. Both sides send arbitrary-length values.

>degradation.

In this proposal, server never "requests" any particular size. The client offers its value in the extended_random extension, and the server offers its value in the reply.

>  Our prototype implementation allows servers to ignore or

...which is a good reason why we abandoned the "request a size" semantics.

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael Gray <[email-masked]>
Date: Wed, 7 Oct 2009 11:33:49 +1000

Paul Hoffman <[email-masked]> wrote on 07/10/2009 10:16:38 AM:

> In this proposal, server never "requests" any particular size. The
> client offers its value in the extended_random extension, and the
> server offers its value in the reply.
>

In this case should be this draft also indicate that the client MAY
generate a fatal "handshake_failure" alert in the event that the Server
provides insufficient data?

Would this again be true for the Server, if a Client sends insufficient
data? i.e. A Server MAY generate a fatal "handshake_failure" alert in the
event that the Client provides insufficient data?

Additionally, can the Server use the Client size as an indication of how
much the Server should send? else how does the Client convey a
minimum/desired requirement information to a Server?

Mick Gray
IBM

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 6 Oct 2009 19:36:47 -0700

>event that the Client provides insufficient data?

Either side MAY decide for many reasons to stop when they see the other sides's extension. I can add something to this effect to the next draft.

>minimum/desired requirement information to a Server?

It doesn't. This is really a different set of semantics than the previous draft. We realized that there was too many expectations being signalled, and decided to simplify.

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael Gray <[email-masked]>
Date: Wed, 7 Oct 2009 16:07:02 +1000

Paul Hoffman <[email-masked]> wrote on 07/10/2009 12:36:47 PM:

> Either side MAY decide for many reasons to stop when they see the
> other sides's extension. I can add something to this effect to the next
draft.
> It doesn't. This is really a different set of semantics than the
> previous draft. We realized that there was too many expectations
> being signalled, and decided to simplify.

IMHO the previous draft was easier from a Server configuration point of
view.  We want our Server configuration to be as simple and accommodating
as possible to minimize the number of configuration options our consuming
products need to deal with, which also simplifies things for our customers.
Thus in the previous draft version we needed  no Server configuration by
default in that the Server comes preconfigured with a default safe maximum
value.  Thus what ever the Client asks for, the Server will both accept and
provide, up until it’s maximum default configuration without needing a
configuration update from a customer.

We ended up with two optional configuration values for a Server: A optional
value for the Maximum amount of random data it will provide on request, and
an optional value for Minimum amount that the Server will accept from a
Client i.e. the Server MUST receive this minimal amount of additional PRF
input.

In this draft we could have the Server always respond with it’s Maximum
safe value or force the customer to always set a configuration value which
immediately causes customer pain.  Sending the maximum safe value seems an
over kill if the client does not need or want it; the client is after all
indicating how much it wants to add on it's side to the PRF and it seems
intuitive IMO for the Server to play ball and respond in kind.  If the
customer then makes the Server configuration value too small we could have
handshake fails with certain clients, reducing Server availability, a
situation that will require problem determination to resolve, and related
customer annoyance.

Mick Gray
IBM

---

From: <[email-masked]>
Date: Mon, 26 Oct 2009 09:11:00 +0100

I agree with Simon here that in the minimum, the extension should have
a "type" field to ensure that if the recipient parses the information,
it's using the same format as the sender. (Some other protocols use
the Enterprise Number registry for "vendor specific" payloads, instead
of creating a new FCFS registry.)

However, I'd like to re-iterate my earlier concern about the original
draft-rescorla-tls-opaque-prf-input draft: this defines a basically
general-purpose extension mechanism to TLS.

We already have a well-defined extension mechanism for TLS (TLS
extensions), which would allow people to do exactly the sorts of
things envisioned in Section 1.1. Its only "drawback" is that it
requires going through the IETF process to obtain the IANA allocation,
and thus publicly documenting what you're doing.

The main "feature" of this draft seems to be allowing "interesting"
extensions without going through the IETF process, or even publicly
documenting what you're doing.  I can certainly see that folks at NSA
might be interesting in doing exactly such things, and they could have
(in their opinion) good reasons.  And some other IETF protocols do
indeed allow pretty much unlimited vendor extensibility (by e.g.
allowing "Vendor Specific" payloads anywhere).

But if the WG decides that adding such extensibility to TLS is a good
idea, I would predict that many folks will use this mechanism to
define new TLS extension so that they can avoid the somewhat
time-consuming process of consensus-building and standardization.

Many of the existing TLS extension could have been done by specifying
suitably "structured" PRF inputs: client/server_authz, user_mapping,
trusted_ca_keys, server_name, status_request, etc. (In these cases,
it doesn't really matter if the input gets fed to PRF; the interesting
part is adding a free-form payload to ClientHello/ServerHello without
requiring an extension number from IANA.)

I know sevaral people have occasionally been frustrated that it's very
difficult to extend TLS (since the requirements for IANA allocation
are quite strict). Personally, I view this as a feature, and I think
it has contributed to general interoperability of TLS/SSL -- it's
generally viewed as a protocol that "just works" (compared to some
other protocols which have large numbers of optional extensions, and
it's very difficult to get implementations from different vendors
to interoperate).
 
Best regards,
Pasi 
(not wearing any hats)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Simon Josefsson
> Sent: 06 October, 2009 16:34
> To: Paul Hoffman
> Cc: [email-masked]
> Subject: Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-
> 00.txt
> 
> two

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 26 Oct 2009 08:22:48 -0700

I understand your concern, but the fact is that there is already an
unofficial extension mechanism available.  Simply create a private
cipher suite (first byte 0xFF) and then define your own formats for
ServerKeyExchange and ClientKeyExchange handshake messages to go
along with it.  This won't work if the client needs to send info
to the server first, though.

Mike

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Oct 2009 14:41:43 -0400

Pasi:

>I'd like to re-iterate my earlier concern about the original

I do not think this is a fair characterization.  TLS extensions 
cannot provide additional PRF inputs.  To my eyes, that is the 
fundamental difference here.

Russ
(also with no hats on)

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Oct 2009 11:55:49 -0700

Timing is everything. A few hours before Pasi sent this, I turned in the -01 which addressed Simon's concerns and started to address Pasi's.

>of creating a new FCFS registry.)

For the -01, I chose a FCFS registry that requires an RFC. Requiring an RFC will increase interop.

>and thus publicly documenting what you're doing.

That is not the only drawback. The whole purpose of this document is to put additional material in the PRF; that is not covered in the TLS Extensions document, nor should it be.

>documenting what you're doing. 

No, the main feature is to allow light-weight extensions (that is, ones that just contain content, not directives) to have input to the PRF.

>I can certainly see that folks at NSA

This is confusing. Are you saying you *want* the equivalent of IKE's Vendor ID payload as a TLS extension? If so, someone could write such an extension; I see no reason why that material would need to be mixed into the PRF using the mechanism I am proposing here. If you don't want a Vendor ID equivalent, that's fine, and I agree, but I don't understand why you brought it up this way.

>time-consuming process of consensus-building and standardization.

Note that the registry in -01 is for "any RFC", not "standards track RFC". I'm happy to make it "standards track RFC required" and have it be parallel to the current TLS extensions requirements.

>requiring an extension number from IANA.)

It would be quite confusing to modify the current TLS extensions mechanism to have some extensions mix content into the PRF but some not. This is why I am proposing a different mechanism altogether. If you want the two mechanisms to have the same requirements, that's fine.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 Oct 2009 13:51:43 -0500

> fundamental difference here.

Well, one could imagine a plethora of extensions each of which says that
you must modify the PRF computation in such and such ways.  But that
gets ugly very quickly.

IMO we need this draft, and IMO it's properly seen as the TLS equivalent
of the GSS-API channel bindings input to GSS_Init/Accept_sec_context():

    An additional PRF input is an octet string that is checked for
    equality in an integrity protected manner that adds no round-trips
    nor half round-trips.  If the equality comparison fails then
    authentication fails.

Whether that facility is used for bonafide channel binding or, more
likely, to provide integrity protection for application data sent out of
band from TLS, is not important.  What's important is: a) that those
semantics are desirable, b) that client and server applications can
agree on what they'll use as additional PRF inputs (e.g., it may be
desirable to support multiple additional inputs, each tagged with a type
specifier).

Nico
--

---

From: <[email-masked]>
Date: Tue, 27 Oct 2009 13:44:14 +0100

> fundamental difference here.

Well, this very document (a proposal for a TLS extension) is a 
proof that TLS extensions can indeed change what goes into the PRF!

So there's no a priori reason why other TLS extensions cannot
do that, too. New TLS cipher suites routinely change what goes into 
the PRF by defining suitable pre_master_secret formats (e.g. RFC 4279).  
And we've had a proposal for a TLS extension that changed the TLS PRF 
to some other PRF. 

Best regards,
Pasi
(not wearing any hats)