Subject: [TLS] Updated TLS 1.2 I-D

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 Jun 2006 09:54:30 -0700

I've submitted an update TLS 1.2 I-D an in the meantime
you can find it at:

http://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt

The big thing I know is misisng is replaceable PRFs, which
I wanted to discuss on the mailing list before I put in.
As people will recall, there was a consensus on replaceable
PRFs/KDFs in Dallas but we didn't discuss exactly how to do
them.

My proposal is as follows:

- All PRFs must have the same "API" as the existing TLS 
  PRFs.
- New cipher suites MAY have as part of their specification
  a new PRF.
- There is no way to separately negotiate a new PRF for
  an existing cipher suite.

The major alternative is some kind of extension, which makes
me uncomfortable. 

Thoughts? Issues?
-Ekr

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

---

From: "Kyle Hamilton" <[email-masked]>
Date: Sun, 25 Jun 2006 22:21:19 -0700

I'm curious, why does having it as an extension make you
uncomfortable?  The way I see it, the PRF will need to be the same on
both sides in order for the handshake to complete, even if it's
negotiated via extension.  If it's not, then the server (and/or the
client) will get what should be the handshake_complete packet, and be
unable to decrypt it properly.  When they do, they'll run the hash
over it, see that it doesn't match, and throw a decrypt_error or
decode_error fatal alert.

Though this would be a good way for Mallory to mount a DOS attack
against the server and/or client (insert an extension to select the
PRF), that possibility is already incumbent in the handshake protocol
regardless (and has been there since at least TLS 1.0, allowing extra
data (which later became 'extensions') after the end of the
client_hello).

An extension of this type (and let's face it, 'extensions' were
introduced so that the protocol could be extended beyond its original
capability), even though it is recommended not to be put in place,
appears to be cryptographically sound.

I've got a couple of comments and questions on the draft (and
protocol) itself; I'll put them in a separate email.

-Kyle H

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 26 Jun 2006 11:55:22 +0200

> The major alternative is some kind of extension, which makes

Extensions shouldn't be worse than additional ciphersuites.  The
problem about additional ciphersuites is that we'd have to duplicate
the number of allocated ciphersuites numbers to provide new PRFs for
otherwise well-known ciphersuites, and issue a number of boring RFCs
to get there.  And that's assuming that there's just a single
preffered new PRF, since otherwise we might end up triplicating,
quadruplicating, ..., the number of allocated ciphersuites (and we
only have a 16-bit namespace).

My preference would be for a new PRF that automatically is plugged
into all existing ciphersuites for the new protocol version.  I.e.,
protocol version negotiation and not ciphersuite negotiation
determines the PRF.  An extensions could be optional for those
who want to negotiate some PRF other than this default.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 26 Jun 2006 14:48:09 +0200

> I've submitted an update TLS 1.2 I-D an in the meantime
The text lists

         enum {
             server_name(0), max_fragment_length(1),
             client_certificate_url(2), trusted_ca_keys(3),
             truncated_hmac(4), status_request(5),
          cert_hash_types(6), (65535)
         } ExtensionType;

According to IANA we have:

    6   user_mapping                  [RFC-santesson-tls-ume-07.txt]

and the tls-srp draft has been using 6 since years, too.

I also note that IANA has assigned temporarily three alert numbers
referencing tls-srp. 

Well, all that didn' happen on June 6, 2006, but close to. :-)

Who will get 7? psk?
 
Have fun.

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

---

From: <[email-masked]>
Date: Mon, 26 Jun 2006 16:30:57 +0300

ExtensionType value 6 has also been used in draft-ietf-tls-pathsec
(presumably dead, as its from 2001), draft-shacham-tls-fast-track
(also dead, from 2002), and some early versions of draft-ietf-tls-ecc,
making it the most popular TLS extension number ever :-)

But seriously speaking, the numbers are assigned by IANA *after* the 
document has been approved by IESG; draft authors should just use 
"TBD-BY-IANA" (and most current drafts, including tls-srp, do this).

(BTW, draft-ietf-tls-psk has been RFC 4279 for some while; it 
did not need an ExtensionType number.)

Best regards,
Pasi

> -----Original Message-----
> From: ext Peter Sylvester [mailto:[email-masked]] 
> Sent: 26 June, 2006 15:48
> To: Eric Rescorla
> Cc: [email-masked]
> Subject: Re: [TLS] Updated TLS 1.2 I-D
> 
> 
> Eric Rescorla wrote:
> I also note that IANA has assigned temporarily three alert 
> numbers referencing tls-srp. 
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Jun 2006 06:42:55 -0700

Bodo Moeller <[email-masked]> writes:

> into all existing ciphersuites for the new protocol version.

Yes, that's my plan.

>  I.e.,

But the flip side of using extensions that way is that we
move more and more of the protocol into extensions. I wonder
if it's becoming time to consider breaking up the ciphersuite
into orthogonal parameters.

-Ekr

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 26 Jun 2006 15:53:49 +0200

> Who will get 7? psk?

psk does not use TLS extensions.
Badra

---

From: <[email-masked]>
Date: Mon, 26 Jun 2006 17:20:27 +0300

>   an existing cipher suite.

I like this approach; it's simple, and I'm not convinced that anything
more complicated is needed. As was already pointed out some time ago,
even the current PRF looks quite secure: if someone really needs a
special PRF due to e.g. regulatory requirements, they'll probably 
need a new ciphersuite anyway.

However, I would take the approach even further towards simplicity:
use the current TLS PRF for all existing ciphersuites (instead of
tying it to the ciphersuite's MAC algorithm). Or in other words:
consider PRF as a property of the ciphersuite's key exchange 
algorithm (instead of the TLS protocol version or a property
that can be negotiated independent of key exchange algorithm).

(The document would then need a couple of new ciphersuites for 
the new PRF, but probably not very many combinations; after all,
if someone's worried that the current PRF is insecure, they're
not likely to use RC4 or IDEA. Maybe these new ciphersuites
could be the combined-mode ones.).

Best regards, 
Pasi

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 26 Jun 2006 17:34:11 +0200

> that can be negotiated independent of key exchange algorithm).

If you take into account SSL 3.0, then the PRF already *is* a property
of the TLS protocol version, though.  And the current TLS PRF, with
its input-splitting dual-hash construction, is somewhat bizarre, so a
reasonable simple new PRF, based on a wider hash, wouldn't be bad --
providing the advantage that those who want to avoid the current
TLS PRF in their favorite ciphersuites won't have to define additional
ciphersuites just to get another PRF, as long as they are reasonably
happy with the new default if we decide on one.

> could be the combined-mode ones.).

This wouldn't be too many new ciphersuites if you consider just those
that are in the main TLS specification.  But then there are other
ciphersuites in other RFCs, so we have to expect to see updates of
these for the new PRF too if the PRF is not tied to the protocol
version.  Unless a single RFC does this for the ciphersuites from
different existing RFCs (which do not even share a common status),
this wouldn't really provide simplicity -- we'd have to expect a
multitude of RFCs defining new ciphersuites, possibly most of them
using the same PRF, possibly with some hand-tailored PRFs that are
slightly optimized for the specific ciphersuites.  Even if a single
RFC does this for ciphersuites originally coming from different RFCs,
the complete ciphersuite table would grow in length and entropy.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 26 Jun 2006 17:55:56 +0200

Understood. Thanks.

---

From: <[email-masked]>
Date: Mon, 26 Jun 2006 18:58:04 +0300

Bodo Moeller wrote:
> If you take into account SSL 3.0, then the PRF already *is* a
> property of the TLS protocol version, though.  And the current TLS
> PRF, with its input-splitting dual-hash construction, is somewhat
> bizarre, so a reasonable simple new PRF, based on a wider hash,
> wouldn't be bad -- providing the advantage that those who want to
> avoid the current TLS PRF in their favorite ciphersuites won't have
> to define additional ciphersuites just to get another PRF, as long
> as they are reasonably happy with the new default if we decide on
> one.

Hmm... this is true. And we do have a precedent for TLS version
dependent properties in ciphersuites: when we added an explicit IV 
for CBC mode ciphersuites in TLS 1.1, we didn't give new numbers
(e.g. "TLS_RSA_WITH_AES_128_CBC_EXPLICITIV_SHA").

So perhaps Eric's proposal (PRF is a property of both the ciphersuite
and protocol version, and for version 1.2, it defaults to the new
to-be-decided PRF unless a ciphersuite spec explicitly says
otherwise) would be simpler after all..

Best regards,
Pasi

---

From: "Anyang Ren" <[email-masked]>
Date: Tue, 27 Jun 2006 07:21:24 -0700

> http://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt

In Section 1.1 Differences from TLS 1.1, you have:

     - Replacement of MD5/SHA-1 combination in the PRF

     - Replacement of MD5/SHA-1 combination in the digitally-signed
     element.

Are you going to replace the MD5/SHA-1 combination in the
verify_data field of the Finished message?

The "Hash" algorithm used in RSA signatures is the same hash
algorithm used in the signature of the certificate.  Although this
is a simple way to choose the "Hash" algorithm, the chosen hash
algorithm really reflects the capability of the CA that issued the
certificate as opposed to the capability of the certificate's subject
(the server or the client). For example, the CA may sign a server
certificate that contains an RSA public key using DSA, and "Hash"
would be SHA-1 because the signature of the certificate is a DSA
signature.

The DSS signatures are hardcoded to use SHA-1. Are you planning
to support extensions of DSA for the SHA-2 algorithms (as in Draft
FIPS 186-3)?

Any interest in adding SHA-384 to the enumerated HashType defined
in 7.4.1.4.7? The current definition of HashType seems to imply that
CAs don't plan to sign certificates with SHA-384 in the signatures.

Anyang Ren
Open source developer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Jun 2006 07:24:38 -0700

> verify_data field of the Finished message?

It's already done. The PRF is used to create the verify_data.

> would be SHA-1 because the signature of the certificate is a DSA

Yes. This is a hueristic, but it's the one we have. Since it seems
like a generally safe assumption that you can verify your own
cert, I don't think there's a problem here.

> to support extensions of DSA for the SHA-2 algorithms (as in Draft

Yes.

> CAs don't plan to sign certificates with SHA-384 in the signatures.

I don't personally hear much interest in that. How do other
WG members feel?

-Ekr

---

From: "Anyang Ren" <[email-masked]>
Date: Tue, 27 Jun 2006 07:44:00 -0700

> It's already done. The PRF is used to create the verify_data.

I was referring to the definition of verify_data in Section 7.4.10.
Finished on page 65:

       struct {
           opaque verify_data[12];
       } Finished;

       verify_data
           PRF(master_secret, finished_label, MD5(handshake_messages) +
           SHA-1(handshake_messages)) [0..11];

The input to the PRF still contains the concatenation of MD5 and SHA-1 hashes.

Anyang Ren
Open source developer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Jun 2006 07:51:27 -0700

> The input to the PRF still contains the concatenation of MD5 and SHA-1 hashes.

No, we're going to feed in the handshake messages directly. I just
forgot to change that.

-Ekr

---

From: <[email-masked]>
Date: Fri, 30 Jun 2006 15:38:01 +0300

Eric Rescorla wrote:

> > certificate as opposed to the capability of the certificate's
> > subject (the server or the client). For example, the CA may sign a
> > server certificate that contains an RSA public key using DSA, and
> > "Hash" would be SHA-1 because the signature of the certificate is
> > a DSA signature.
> 

I agree with Anyang's concerns to some degree; an explicit negotiation
would be better than a heuristic. But since the draft already has
cert_hash_types extension, couldn't we use it to also specify what
algorithms are supported for the "Signature" construct?

(BTW, it would be useful if the server could also indicate to the
client which hash functions it supports, e.g. for client
authentication).

<snip>

> I don't personally hear much interest in that. How do other

Including SHA-384 would make the list match PKCS#1 (except for MD2,
but I guess that's obsolete)... so maybe it would like nicer?

Best regards,
Pasi