Subject: [TLS] TLS 1.2 draft

From: EKR <[email-masked]>
Date: Sun, 04 Mar 2007 21:41:58 -0800

I've just submitted a revised draft-ietf-tls-rfc4346bis-03.

Until it shows up, you can find a copy at:
https://svn.resiprocate.org/rep/ietf-drafts/ekr/tls/tls.txt

Here's a list of the major changes in this version. I'll
post a list of the few remaining open issues soon.

-Ekr

   [RFC Editor: Please delete this]

     - Forbid decryption_failed [issue 5]

     - Fix CertHashTypes declaration [issue 20]

     - Fix client_version in 7.4.1.2 [issue 19]

     - Require Bleichenbacher and timing attack protection [issues 17
   and
     12].

     - Merged RFC-editor changes back in.

     - Editorial changes from NIST [issue 8]

     - Clarified the meaning of HelloRequest [issue 39]

     - Editorial nits from Peter Williams [issue 35]

     - Made maximum fragment size a MUST [issue 9]

     - Clarified that resumption is not mandatory and servers may
     refuse [issue 37]

     - Fixed identifier for cert_hash_types [issue 38]

     - Forbid sending unknown record types [issue 11]

     - Clarify that DH parameters and other integers are unsigned [issue
   28]

     - Clarify when a server Certificate is sent [isssue 29]

     - Prohibit zero-length fragments [issue 10]

     - Fix reference for DES/3DES [issue 18]

     - Clean up some notes on deprecated alerts [issue 6]

     - Remove ephemeral RSA [issue 3]

     - Stripped out discussion of how to generate the IV and replaced it
   with a randomness/unpredictability requirement [issue 7]

     - Replaced the PKCS#1 text with references to PKCS#1 v2. This also
   includes DigestInfo encoding [issues 1 and 22]

     - Removed extension definitions and merged the ExtendedHello
   definitions [issues 31 and 32]

     - Replaced CipherSpec references with SecurityParameters references
   [issue 2]

     - Cleaned up IANA text [issues 33 and 34]

     - Cleaned up backward compatibility text [issue 25]

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

---

From: Nelson B Bolyard <[email-masked]>
Date: Mon, 05 Mar 2007 17:22:56 -0800

> post a list of the few remaining open issues soon.

Eric,

Where can one find the numbered list of issues to which your comments refer?

Also, the server of the URL you gave above seems to hang after delivering
the first 5.5 pages of the draft.  I have tried it repeatedly with the
same results each time.  I hope it can & will be fixed.

Regards,

/Nelson Bolyard

>    and 12].
>      - Clarify that DH parameters and other integers are unsigned [issue 28]

---

From: EKR <[email-masked]>
Date: Mon, 05 Mar 2007 17:29:01 -0800

> Where can one find the numbered list of issues to which your comments refer?

Pasi has created a tracker at:

http://www1.tools.ietf.org/wg/tls/trac/

If there's an issue you think should be on here but isn't, please
post to the list. [I'll be starting a discussion about alert mandatoriness
in response to one of NISTs issues and the one you raised shortly.]

> same results each time.  I hope it can & will be fixed.

Me too, but I don't control it, since it's a resiprocate svn repository
I just leech off of. Presumably the draft will be up on the IETF site in
the not too distant future.

-Ekr

---

From: Nelson B Bolyard <[email-masked]>
Date: Mon, 05 Mar 2007 17:48:55 -0800

> in response to one of NISTs issues and the one you raised shortly.]

Thanks, Eric,

This URL gives me the full list in ascending numeric order:

<http://www1.tools.ietf.org/wg/tls/trac/query?status=new&status=assigned&status=reopened&status=closed&order=id>

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 Mar 2007 09:41:29 +0100

>    includes DigestInfo encoding [issues 1 and 22]

The new text is:

   In RSA signing, the opaque vector contains the signature generated
   using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1B].  As
   discussed in [PKCS1B], the DigestInfo MUST be DER encoded and for
   digest algorithms without parameters (which include SHA-1) the
   DigestInfo.AlgorithmIdentifier.parameters field SHOULD be omitted but
   implementations MUST accept both without parameters and with NULL
   parameters. Note that earlier versions of TLS used a different RSA
   signature scheme which did not include a DigestInfo encoding.

The PKCS#1 v2.1 with erratas, RFC 3447 and IEEE 1363a-2004 includes
hash identifier for SHA-1 that corresponds to a present NULL
parameter:

      SHA-1:   (0x)30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 || H.

Right now, GnuTLS generates NULL and only accepts NULL values.  Mike's
server generate NULL, and if I remember correctly, it was based on
OpenSSL.  I am not aware of any other TLS 1.2 servers or clients that
are available for testing.

/Simon

---

From: <[email-masked]>
Date: Tue, 6 Mar 2007 14:11:48 +0200

> Cleaned up backward compatibility text [issue 25]

This text (in E.2) still needs some cleaning. Currently
it says:

   challenge_length
       The length in bytes of the client's challenge to the server to
       authenticate itself. Historically, permissible values are between
       16 and 32 bytes inclusive. When using the SSLv2 backward
       compatible handshake the client MUST use a 32-byte challenge.
[...]
   challenge
       Corresponds to ClientHello.random. If the challenge length is
       less than 32, the TLS server will pad the data with leading
       (note: not trailing) zero bytes to make it 32 bytes long.

Which is not exactly consistent: if the challenge length MUST be 32
bytes, it can't be less than 32 bytes.

It was also noted that for historical and/or compatibility reasons,
many existing browsers (e.g. Opera, IE6, FireFox 1.5) use 16-byte
challenges:

http://www1.ietf.org/mail-archive/web/tls/current/msg00985.html

My proposal (in the mail linked above) was to to change this to "The
length of the challenge field in bytes; MUST be between 16 and 32
(inclusive)."

Comments? (At the very least, the text needs to be internally
consistent. Preferably it should also promote real-world
interoperability and reflect what implementations are expected to do.)

Best regards,
Pasi

---

From: Mike <[email-masked]>
Date: Tue, 06 Mar 2007 06:21:16 -0800

You could say that the random length MUST be between 16 and 32
bytes, and add that it SHOULD be 32 bytes.

Mike

---

From: EKR <[email-masked]>
Date: Tue, 06 Mar 2007 07:20:06 -0800

> interoperability and reflect what implementations are expected to do.)

So, here's what I was trying to say:

1. As a TLS 1.2 impl yuou MUST use a 32-byte challenge.
2. Downrev impls may use a 16-32 byte challenge at which point
   you would pad with zeros but in < 1.2 mode.

That may not be the right thing to say. :)

-Ekr

---

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 06 Mar 2007 07:47:21 -0800

> are available for testing.

NSS hasn't implemented TLS 1.2 yet, but supports the
RSASSA-PKCS1-v1_5 signature scheme.  NSS generates NULL parameters
but accepts both without parameters and with NULL parameters.

I was surprised to learn about this change when I read your message.
So I did some research.  Here is what I found.

Appendix H of RFC 3447 explains the change to recommend omitting
the parameters for the SHA-x hash algorithms defined by NIST:

    The following corrections were made in converting the PKCS #1 v2.1
    document to this RFC:

    *  The requirement that the parameters in an AlgorithmIdentifier
       value for id-sha1, id-sha256, id-sha384, and id-sha512 be NULL was
       changed to a recommendation that the parameters be omitted (while
       still allowing the parameters to be NULL). This is to align with
       the definitions originally promulgated by NIST. Implementations
       MUST accept AlgorithmIdentifier values both without parameters and
       with NULL parameters.

    [...]

    These corrections will be reflected in future editions of PKCS #1
    v2.1.

This change has been made to PKCS #1 v2.1 in the errata.
(ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt)

As you pointed out, the authors of RFC 3447 forgot to update the
DER encoding of the DigestInfo values for SHA-1, SHA-256, SHA-384,
and SHA-512.  The DER encoding still contains the NULL parameters
(the 05 00 octet sequence near the end).

Wan-Teh

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Mar 2007 18:12:12 +0100 (MET)

>      - Remove ephemeral RSA [issue 3]

This makes me sad.

I would have SIGNIFICANTLY preferred if temporary/ephemeral RSA
had been retained and the restriction to the RSA_EXPORT ciphersuites
had been removed instead.

As I had previously explained, the use of temporary/ephemeral RSA
with same-strength keys as the server's certificate would make
key-stealing of the servers' key much less useful for passive
attacks.

-Martin

---

From: EKR <[email-masked]>
Date: Tue, 06 Mar 2007 09:22:29 -0800

> key-stealing of the servers' key much less useful for passive

The recommendation is to use RSA/DHE for these applications. Can
you explain why you think ephemeral RSA is superior?

Thanks,
-Ekr

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Mar 2007 18:40:46 +0100 (MET)

> you explain why you think ephemeral RSA is superior?

The Server's RSA key is typically used for at least one year
(or longer if renewal just extends the cert lifetime and keeps
 the key/keypair).

If an attacker gets hold of the Servers private RSA key, he can
passively monitor (decrypt) all sessions using a RSA-based ciphersuite.

When a temporary/ephemeral keypair is used for key exchange, then
possession of the private RSA key will not be sufficient to
passively monitor (decrypt) SSL sessions with the server
using an RSA ciphersuite with a temporary/ephemeral keypair.
It will require an active (MITM) attack.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 06 Mar 2007 09:46:22 -0800

> It will require an active (MITM) attack.

Right. I understand this point.

What I'm saying is that the recommendation to prevent his attack
is to use an RSA_DHE ciphersuite and use a fresh DH ephemeral
with each key exchange. This provides the same security at
a substantially superior performance level.

-Ekr

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 06 Mar 2007 18:00:14 +0000

> a substantially superior performance level.

On the subject of DHE and performance... should we allow a server to
optionally send the subprime ("q") value in ServerKeyExchange?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 06 Mar 2007 18:03:02 +0000

Wan-Teh Chang wrote:
> 
> NSS generates NULL parameters

OpenSSL does this also.

Steve.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 07 Mar 2007 10:53:00 +0100

Eric Rescorla <[email-masked]> writes:

> is to use an RSA_DHE ciphersuite

I agree with that.  However, if I remember correctly, DHE key
exchanges are generally slower than plain RSA key exchanges with
temporary keys, although it depends on the DH group size.

> and use a fresh DH ephemeral with each key exchange. This provides
> the same security at a substantially superior performance level.

Generating a fresh DH ephemeral with each key exchange would deplete
the entropy in many RNG's.

Perhaps we could discuss the frequency that DH ephemeral's should be
changed, possibly also in the document.

There are tools out there that use a static hard-coded DH ephemeral in
the code, and some configurations where the DH ephemeral is stored in
a separate file, but never re-freshed anyway.

I can't find an appropriate section, but section 8.1.2 seems as good
as any, so I suggest adding this to the end of it:

   When ephemeral DH parameters are needed, they SHOULD be re-freshed
   with some interval appropriate for the local environment.  This MAY
   be for each new key exchange, but MAY also be each day, week or
   month.

That's quite fuzzy, but I'm not sure there are any good
recommendations on this.  In GnuTLS, I think we recommend to change
the DH ephemeral somewhere around each day or week.

The change frequency is related to the size of the DH group, I guess,
and it would be interesting to know what sizes others default to?
GnuTLS uses 1024 bit DHE parameters by default.

/Simon

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 7 Mar 2007 07:08:19 -0500

On Wed, 07 Mar 2007 10:53:00 +0100

> temporary keys, although it depends on the DH group size.

The problem is generating the two large primes for the RSA key pair.

> changed, possibly also in the document.

I think the strategy used in JFK
(http://www.cs.columbia.edu/~smb/papers/jfk-ccs.pdf) would help.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: <[email-masked]>
Date: Wed, 7 Mar 2007 15:59:22 +0200

> >      - Remove ephemeral RSA [issue 3]

One clarification about this: ephemeral RSA was already removed 
in TLS 1.1 (RFC 4346); issue 3 was an editorial correction to 
some old text that was still lying around.

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 7 Mar 2007 16:22:58 +0200

Wan-Teh Chang wrote:

>        value for id-sha1, id-sha256, id-sha384, and id-sha512 be
>        NULL was changed to a recommendation that the parameters be
>        omitted (while still allowing the parameters to be
>        NULL). This is to align with the definitions originally
>        promulgated by NIST. Implementations MUST accept
>        AlgorithmIdentifier values both without parameters and with
>        NULL parameters.
> 
>     [...]
> 

No, this is not exactly what pkcs-1v2-1errata.txt says; there
is additional text in the errata:

  Exception: When formatting the DigestInfoValue in EMSA-PKCS1-V1.5 
  (see 9.2), the parameters field associated with id-sha1, id-sha256, 
  id-sha384 and id-sha512 SHALL have a value of type NULL. This is to 
  maintain compatibility with existing implementations and with the 
  numeric information values already published for EMSA-PKCS1-V1.5 
  which are also reflected in IEEE 1363a-2004[27].

In other words: AlgorithmIdentifier is used in several different
places, and the text "MUST accept both, SHOULD omit" applies to 
all of those *except* one place (EMSA-PKCS1-V1.5). But that place
happens to be the one we care about for TLS 1.2 (ServerKeyExchange
and CertificateVerify messages)!

I think we should follow pkcs-1v2-1errata.txt and IEEE 1363a-2004
(which both agree) here, unless there are compelling arguments
against it...

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Wed, 7 Mar 2007 15:22:04 +0100 (MET)

> The problem is generating the two large primes for the RSA key pair.

I agree that a full RSA keygen, in particular for same-size (>=1024 bit)
temporary RSA keypairs as the servers certificate is a sure
performance-killer.

However, the protocol does not preclude the use of an SSL servers
temporary keypair for multiple handshakes, say one or a few hours.
SSH servers have been doing this for years.

I admit to have very little experience with most crypto math and
never implemented cryptographic algorithms myself.
I do maintenance on code that implements RSA, but I have never
looked at code for DH, so I can not really comment on that.

-Martin

---

From: <[email-masked]>
Date: Wed, 7 Mar 2007 17:26:25 +0200

Simon Josefsson wrote:

> Generating a fresh DH ephemeral with each key exchange would 
> deplete the entropy in many RNG's.

The normal RSA ciphersuites require far more bytes from PRNG for 
each key exchange (although only on the client side), and I 
haven't heard that this would be a significant problem.

<snip>
>    When ephemeral DH parameters are needed, they SHOULD be
>    re-freshed with some interval appropriate for the local
>    environment.  This MAY be for each new key exchange, but MAY also
>    be each day, week or month.
> 

Considering that generating fresh DH private value costs about 
the same as one TLS handshake with DHE, I'd say even a day
would be a very large interval.

IKEv2 took the view that since this doesn't affect interoperability, 
there's no need to mandate anything in the spec (RFC 4306, Section
2.12).

However, maybe some guidance would be helpful (especially if there
really are implementations that store the "ephemeral" DH key in
a file!). Earlier, I also suggested that we should recommend *against*
generating new DH domain parameters:

http://www1.tools.ietf.org/wg/tls/trac/ticket/35

Eric responded that this is not specific to TLS, and could be a 
separate document. That's of course true, but currently we don't 
have any normative dependency to documents that explain 
how to do DH securely. And I do agree with the sentiment expressed 
in IETF67's SAAG presentation that RFCs should include advice on 
how to implement them securely (especially for things that
people earlier have gotten wrong).

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 7 Mar 2007 17:30:46 +0200

> That may not be the right thing to say. :)

Ok, now I understood what you meant. But perhaps this spec is 
not really the right place to say what e.g. TLS 1.0 implementations 
should do when TLS 1.0 is negotiated :)

I'd be OK with Mike's proposal ("length MUST be between 16 and 32
bytes, and add that it SHOULD be 32 bytes").

Best regards,
Pasi

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 07 Mar 2007 07:32:49 -0800

> and CertificateVerify messages)!

Pasi, you're right.  Thank you for correcting me.  I didn't
see the Exception paragraph.  This is complicated.

> (which both agree) here, unless there are compelling arguments

Since pkcs-1v2-1errata.txt (Dec. 2005) is newer in RFC 3447
(Feb. 2003), I agree with your recommendation.

Wan-Teh

---

From: EKR <[email-masked]>
Date: Wed, 07 Mar 2007 08:10:16 -0800

> temporary keys, although it depends on the DH group size.

This is discussed pretty extensively in "SSL and TLS". From memory, on
the server side there are three time consuming steps in the ephemeral
RSA computation:

 1. Generating the ephemeral RSA key
 2. Signing the ephemeral RSA key with the static RSA key.
 3. Decrypting the PMS encrypted under the ephemeral RSA key.

The first can be amortized over a large number of transactions,
so really we're talking about (2) and (3). 

In RSA-DHE, there are three costs as well:

 1. Generating the DH ephemeral.
 2. Signing the ephemeral DH key with the static RSA key.
 3. Computing the DH ZZ.

However step 1 can actually be made quite fast by using a short DH
exponent and/or using a squaring table, so the dominant costs are
(2) and (3). (2) is obviously the same, which leaves us with (3), 
which is comparable in both cases.

So, on the server side, the costs are fairly comparable. On the
client side, DHE is much more expensive since you need to do
(1) and (2). But the cost of one computation is typically relatively
small compared to people's perceptual times (order 50 ms) and
clients tend to be low volume, so it's not an issue except for 
very slow machines.

> the entropy in many RNG's.

I don't understand this point. Most TLS implementations use the
PRNG to generate the random values as well as the session IDs.
You quickly get to the point where you've exposed vastly more
bits of entropy than your underlying PRNG state. If your
PRNG can't handle this, you need a new PRNG.

> a separate file, but never re-freshed anyway.

DH has two parts:

1. The group parameters.
2. The ephemeral share (g^x mod p).

The group parameters never need refreshing. The ephemeral share
needs to be secret so hardcoding it sees like a pretty bad idea.
Standard practice is to generate a fresh ephemeral for every
connection but you can amortize if you're careful. In particular,
you have to worry about small subgroup issues so it starts to
get a lot more important to use S-G primes.

I can try to draft up some guidance here based on Zuccheratto's 
S/MIME draft, but if someone (Bodo?) wanted to contribute some
text, I wouldn'tcomplain :)

-Ekr