[TLS] draft-ietf-tls-rfc4346-04 available
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.