Subject: [TLS] draft-ietf-tls-rfc4346-04 available

From: Eric Rescorla <[email-masked]>
Date: Sun, 08 Jul 2007 07:50:51 -0700

I just submitted draft-ietf-tls-rfc4346-04. 

Until it's in the repository, you can find it at:
https://svn.resiprocate.org/rep/ietf-drafts/ekr/tls/tls.txt

The changes are:

     - Added some guidance about checking DH groups and exponents.
     [Issues 15 and 43]

     - DigestInfo now MUST be NULL but must be accepted either way
     per discussion in Prague [Issue 22]

     - Improved versions of Bleichenbacher/Klima/Version number
     text for the EPMS (due to Eronen) [Issue 17]

     - Cleaned up SSLv2 backward compatibility text [Issue 25]

     - Improvements to signature hash agility text [Issue 41].
     Still not completely fixed.

     - Changed cert_hash_types to signature hash types and indicated a
   preference order.

The two open issues I know of are:

1. There is still no requirement that any termination of the connection
   be preceded by a fatal error. I indicated my reasoning in a message
   last night and I haven't seen consensus for this change, nor did
   I see any in the discussion in Prague. If there is a lot of 
   objection here I would ask Pasi to do a strawpoll.

2. There's still a handwave about how to know what hash is to be 
   used with a given signature algorithm. IMO it should be in the
   SPKI of the relevant cert for every algorithm but RSA-PKCS1-v15
   and for backward compatibility, if the cert is bare dsa it
   should be SHA-1. This requires an indicator in the cert,
   however, so we need to at least talk to PKIX about it, hence
   the handwave.

   Also, I deliberately didn't talk about issues with cert types/algorithms
   not mentioned in this draft, i.e., PGP and ECC...

Also, I'm waiting for some additional text from Pasi on implementation
pitfalls.
-Ekr

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

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Tue, 24 Jul 2007 17:25:00 +0200

>      - Added some guidance about checking DH groups and exponents.

I think this:

  "The client SHOULD also verify that the DH public exponent appears to be  
of adequate size."

ought to be worded stronger, perhaps something like

  "The client SHOULD also verify that the DH public exponent is of  
equvalent cryptograhic strength as the key used to sign the public key."

(Yesterday there were two reports to Opera about such weak keys at  
Hushmail)

This might also be phrased in a way that allows it to apply to other  
temporary key methods, as well.

Perhaps there should be some advice on what a client should do in case the  
key is considered too weak?

My suggestion would be that the client should renogiate with the ephemeral  
ciphersuites less preferred than non-ephemeral ciphersuites. The drawback  
is that this will make the negotiation process more complicated.

Another possibility would be to send the insufficient_security alert as a  
warning (which would require redefining the alert) even if the connection  
is accepted.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		                 Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 Jul 2007 09:28:41 -0700

At Tue, 24 Jul 2007 17:25:00 +0200,
> equvalent cryptograhic strength as the key used to sign the public key."

I actually do not agree with this position. There are valid reasons
to use long signing keys and shorter key establishment keys.

-Ekr

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Tue, 24 Jul 2007 19:36:18 +0200

> to use long signing keys and shorter key establishment keys.

Maybe.

Alternatively, I'd like some guidance about how to determine what  
"adequate size" is.

-- 
Sincerely,
Yngve N. Pettersen