[TLS] RE: WGLC for draft-ietf-tls-rfc4346-bis-07

[Stefan Santesson <stefans@xxxxxxxxxxxxx>]

I would like to submit the following Last Call comments on TLS 1.2

1) Terminology: CipherSuite, ciphersuite or cipher suite. And CipherSuites or cipher suites
The document currently includes all flavors of the above term. It would be better to select one form and stick to it.

2) Custom signature/digest algorithms for local use or test purposes.
TLS allows definition of cipher suites for private use (0xFF,0x00-FF). It would be reasonable to also allocate a name space for private use also for hash algorithms and signature algorithms. If not, the private cipher suites can't be used.

3) Multiple hash alternatives.
In order to verify the CertificateVerify message the server must hash previous messages from the client. This can be problematic if the client is still allowed to choose more than one hash algorithm. In this case the server must store all previous messages and hash them after receiving CertificateVerify or hash them with all possible hash algorithms when received. This could open for DoS and flooding attacks, dependent on the server design, if attack messages are constructed to be as long as legally possible. The comment is only to highlight the issue rather than suggesting any changes. The server can mitigate this by always limiting the hash choices to only one hash algorithm in the Certificate Request message. Perhaps this should be mentioned in the security considerations section.

4) Stepping up the choice of hash?
If the client doesn't specify any hash algorithm, the server MUST use SHA-1 in the server key exchange message. (7.4.3) "If no "signature_algorithms" extension is present , the server MUST use SHA-1 as the hash algorithm." The client is however not obligated to declare any signature_algorithms (7.4.1.4.1) "Clients SHOULD send this extension if they support any hash algorithm other than SHA-1."
But what if the server has knowledge that the client does support a better hash? For example, the selected key exchange algorithm is derived from a cipher suite defining a PRF based on a better hash. Would it be reasonable to allow the Server to make use of the better hash algorithm?

5) Error: supported_signature_types -> Supported_signature_algorithms
The following paragraphs in 7.4.4 contains 2 instances of supported_signature_types with is not defined in this spec. Should be "supported_signature_algorithms".

   -  Any certificates provided by the client MUST be signed using a
      hash/signature algorithm pair found in supported_signature_types.

   -  The end-entity certificate provided by the client MUST contain a
      key which is compatible with certificate_types. If the key is a
      signature key, it MUST be usable with some hash/signature
      algorithm pair in supported_signature_types.



Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Pasi.Eronen@xxxxxxxxx [mailto:Pasi.Eronen@xxxxxxxxx]
> Sent: den 27 november 2007 13:58
> To: tls@xxxxxxxx
> Subject: [TLS] WGLC for draft-ietf-tls-rfc4346-bis-07
>
>
> This message starts a WG last call on draft-ietf-tls-rfc4346-bis-07,
> prior to sending it to the IESG for publication as Proposed Standard.
>
> Please send your comments to the WG mailing list by Wednesday
> December 19th. Comments along the lines "I've read it and it looks
> OK" are helpful and encouraged.
>
> The last call period is longer than usual to accommodate for
> the IETF meeting, but if you manage to do some reading on your
> flight to Vancouver, your comments can be discussed face-to-face
> there.
>
> Best regards,
> Pasi
>
>
> _______________________________________________
> TLS mailing list
> TLS@xxxxxxxxxxxxxx
> https://www1.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls