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

From: Stefan Santesson <[email-masked]>
Date: Sun, 2 Dec 2007 03:21:02 +0000

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: [email-masked] [mailto:[email-masked]]
> Sent: den 27 november 2007 13:58
> To: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tls

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 6 Dec 2007 17:15:13 +0100 (MET)

(sorry for being late).

There is one more thing about Client Certs where I consider the
guideline(s) in the existing TLS specs insufficient.

What is a TLS server expected to do when it receives, as a reaction
to a client certificate request, a client certificate message for
which it can not build a chain to one of the known (or permitted)
trust anchors?

There are implementations that will unconditionally abort the
SSL/TLS handshake with a fatal alert.

One possibility would be for the TLS specification to say that
the server should ignore such a client cert and continue as if
the client did not send a certificate.

I think a clearly defined (server) behaviour is important for the new option
that allows the server to send a CertificateRequest with an
__empty__ list of trusted CAs.

When I saw the following message:
=   From: [email-masked] (Peter Gutmann)
=   Subject: Re: [TLS] CertificateRequest
=   Date: Thu, 22 Nov 2007 22:08:38 +1300
=
= [...]
=
= I've found that simply ignoring the contents of the cert request seems
= to work pretty well.  Since there are servers sending out nonsensical
= requests, the safest thing to do is just record that a request for
= a cert exists.  If you have a cert, send it and let the server sort it out. 

IMHO, blindly sending a client cert is only a safe bet if the
spec says that the server should (silently) ignore client certs
which it does not trust.

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 06 Dec 2007 17:57:43 +0100

> __empty__ list of trusted CAs.

Is there any reason why this cannot be up to server policy?

I think that some sites (e.g., bank that uses client certificates) would
want to abort the handshake.  Some other sites (e.g., webmail) would
want to continue as if the client did not send a certificate.

I would agree that a client may want to be able to find out whether the
server was able to successfully verify the client certificate or not,
though.  I don't recall if this is possible today, but I think not.

/Simon

---

From: [email-masked]
Date: Thu, 6 Dec 2007 18:30:03 +0100

Hi,

> though.  I don't recall if this is possible today, but I think not.

Is this really necessary? To me, this appears as something that is
beyond the scope of TLS and better handled on higher layers. What is
the actual use case here?
 
The client can verify the server's identity and thus it knows, which 
certificate(s) the server expects, if it requests one. But it is up 
to the layer above TLS to choose the right certificate and give it
to the TLS handshake engine. Same for actually verifying the 
certificate(s). 
After verifying the server certificate, the client trusts the server to be
authentic. If the server then decides that it accepts a client certificate
that cannot be verified, the server may have its resons for this - 
otherwise
if could simply abort the handshake
If the client is interested in further details why the server accepted
the connection with a certificate that it could not verify, dicussing
further details should happen on the next higher layer without TLS
beeing involved here except for data transport. 

regards, Axel

---

From: Martin Rex <[email-masked]>
Date: Thu, 6 Dec 2007 18:59:27 +0100 (MET)

> Is there any reason why this cannot be up to server policy?

No.  But currently it is implementation defined and the server
administrator may not have the option to configure his preferred
behaviour.

Specifying it should be up to server policy would require implementations
to implement configurable behaviour.

> want to continue as if the client did not send a certificate.

The serious drawback of aborting the handshake is that it will be impossible
to present a meaningful error message to the client/user.  There is an
awfully large installed base of Web Browsers that behaves extremely
braindead when it comes to (fatal) SSL alerts, presenting the end user
extremely useless and misleading error messages.

If the TLS stack continues the handshake and the decision to
reject the request at the application layer, then there is an
established communication channel through which a beautiful,
application-specific error message can be sent to the client
(e.g. some HTML error page in case of a Web-Browser client).

> though.  I don't recall if this is possible today, but I think not.

As I mentioned, for some (server) implementations, this is currently
implicit from the servers reaction to the ClientCertificate message.

With a single client cert in the browser and "select automatically"
configured, it might also be very non-obvious whether a client
certificate request was received and a client certificate was sent.

-Martin

---

From: "tom.petch" <[email-masked]>
Date: Fri, 7 Dec 2007 12:28:05 +0100

----- Original Message -----
From: "Martin Rex" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 06, 2007 5:15 PM
Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4346-bis-07

> which it can not build a chain to one of the known (or permitted)

I think that this needs clarfying but that this I-D is not the place to do it.

I notice another post made reference to an HTTP server as if that were the only
use of TLS; well, no, as you know:-)

My interest is in the use of TLS in device management - syslog, Netconf, ... -
where client authentication is what really matters.  The server might be the
remote, small, underpowered device with little access to infrastructure - think
hub, bridge, router, gateway - which needs to know that this client - big, fat,
central, over-endowed workstation - which is telling it to reboot really is the
one with authority to do so.

So I am thinking that rather than each WG try to come up with its own idea of
applicability - eg draft-ietf-syslog-transport-tls-11.txt,
draft-badra-tls-netconf-02.txt - more guidance on applicability and usage from
this WG would serve the IETF better.

Tom Petch

> =   Date: Thu, 22 Nov 2007 22:08:38 +1300
<snip>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 Dec 2007 23:28:01 +0000

As most of the feedback to these comments were made during the IETF meeting, I summarize them here.

Issue 1) Accepted. Terminology will be harmonized.
Issue 2) Accepted. Experimental ranges will be added to hash and Signature algorithm IANA assignments.
Issue 3) Accepted as update to Security Considerations
Issue 4) Not accepted. I will follow up on this in separate mail.
Issue 5) Accepted. Error will be corrected.

Stefan Santesson
Senior Program Manager

> From: Stefan Santesson [mailto:[email-masked]]
> Sent: den 1 december 2007 19:21
> To: [email-masked]; [email-masked]
> Subject: [TLS] RE: WGLC for draft-ietf-tls-rfc4346-bis-07
>
> The document currently includes all flavors of the above term. It would
> be better to select one form and stick to it.
>
> 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.
>
> 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.
>
> 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?
>
> 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".
>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 Dec 2007 23:40:13 +0000

> Would it be reasonable to allow the Server to make use of the better

This was discussed at the TLS meeting and not accepted mainly for the following reasons:

1) It would be very hard to specify the specific conditions for when a server can or cannot step up the used hash algorithm.
2) We need servers to behave uniformly on this issue.

I would however challenge condition 2) and if condition 2) is not necessary, then condition 1) falls as well.
Why is it important that all servers are designed to handle this situation uniformly? I fail to see the harm if some servers successfully deploys better security while other servers in the same situation would choose to stick to the default security level.
As long as the server can determine successfully the capacity of the client and successfully communicate the choice of algorithms, then the only thing that can happen is that we would simply allow the server to choose better security.

If there is no need for all servers to provide a uniform behavior then we don't need to specify the exact conditions under which the server can gain knowledge of the client's capacity. This can range from local configuration and local policy to a local convention based on the ciphersuites supported by the client.

Stefan Santesson
Senior Program Manager

---

From: <[email-masked]>
Date: Wed, 12 Dec 2007 13:27:54 +0200

Stefan Santesson wrote:

> 1) It would be very hard to specify the specific conditions 
> for when a server can or cannot step up the used hash algorithm.
> I would however challenge condition 2) and if condition 2) is 
> not necessary, then condition 1) falls as well.
> Why is it important that all servers are designed to handle 
> this situation uniformly? 

Completely uniform server behavior is perhaps not needed, 
but interoperability is.

> I fail to see the harm if some servers successfully deploys
> better security while other servers in the same situation would
> choose to stick to the default security level.
>
> As long as the server can determine successfully the capacity 
> of the client and successfully communicate the choice of 
> algorithms, then the only thing that can happen is that we 
> would simply allow the server to choose better security.
> 
> If there is no need for all servers to provide a uniform 
> behavior then we don't need to specify the exact conditions 
> under which the server can gain knowledge of the client's 
> capacity. This can range from local configuration and local 
> policy to a local convention based on the ciphersuites 
> supported by the client.

Do you mean something along the lines "if the client
proposes ciphersuite TLS_X_WITH_Y, then the server assumes
that the client will also support hash Z, even though
the client didn't include Z in signature_algorithms
extension"?

This sounds like a recipe for horrible interop problems
unless the specification actually says that "all implementations
which support TLS_X_WITH_Y must also support hash Z". While
this could perhaps be done, I don't quite understand why
it would be useful: if the client does indeed support Z, it 
will include it in the signature_algorithms list. If it
doesn't include it, it either doesn't support it, or does
not want to use it (in this context).

Best regards,
Pasi

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 12 Dec 2007 22:30:44 +0000

In line;

Stefan Santesson
Senior Program Manager

> Sent: den 12 december 2007 03:28
> To: Stefan Santesson; [email-masked]
> Subject: RE: WGLC - Stepping up Hash
>
> Stefan Santesson wrote:
>

Great. A interoperability problem that would not be acceptable is if a Server based on how TLS 1.2 is defined, falsely assumes that a client can do hash Z.

> the client didn't include Z in signature_algorithms

Yes and No. No I don't want this assumption to be defined in the protocol. That would be pretty ugly and would have to be defined per cipher suite.
But Yes, the server may have deterministic knowledge that in the pool of clients it serves (or for the particular service it provides) either all clients, or a subgroup of the clients that uses a particular cipher suite, in fact can handle Hash Z.

> not want to use it (in this context).

This is not a matter of when a Server should select hash Z. This is a matter of allowing the server to select hash Z when the server knows that the client can, or must be able to, use hash Z. In this case there can't be any interop issues by definition. As TLS 1.2 currently is written, the Server is prohibited from stepping up the security even if it knows that it would not cause any problems.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Dec 2007 15:06:16 -0800

At Wed, 12 Dec 2007 22:30:44 +0000,
> Yes and No. No I don't want this assumption to be defined in the
> protocol. That would be pretty ugly and would have to be defined per
> cipher suite.  But Yes, the server may have deterministic knowledge
> that in the pool of clients it serves (or for the particular service
> it provides) either all clients, or a subgroup of the clients that
> uses a particular cipher suite, in fact can handle Hash Z.

Yes, it might. But that's contrary to the general goal of
explicit signalling.

> This is not a matter of when a Server should select hash Z. This is
> a matter of allowing the server to select hash Z when the server
> knows that the client can, or must be able to, use hash Z. In this
> case there can't be any interop issues by definition.

I don't agree with this. What you are proposing is that a compliant
client could offer this cipher suite but not be able to accept
a signature with that digest. The server would then present
a certificate with that digest and the client would fail. That's
an interop issue. Yes, you could have some side agreement
between the client and the server, but you've basically
created some new protocol that happens to just look a lot
like TLS 1.2.

> As TLS 1.2
> currently is written, the Server is prohibited from stepping up the
> security even if it knows that it would not cause any problems.

I don't understand why it's a problem to simply have the client
offer the extension in these special cases.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Thu, 13 Dec 2007 02:17:52 +0100 (MET)

> offer the extension in these special cases.

If there is any value in "stepping up" the hash, limiting
its use to the official and correct negotiation in TLS 1.2 is
not only architecturally clean, it also encourages all
implementations capabable of doing it to adopt the interoperable
negotiation -- whereas any permission for meta-knowlege-hacks
might significantly impair adoption of a fully interoperable
negotiation.

-Martin

---

From: <[email-masked]>
Date: Thu, 13 Dec 2007 08:46:56 +0200

Stefan Santesson wrote:

> Yes and No. No I don't want this assumption to be defined in 
> the protocol. That would be pretty ugly and would have to be 
> defined per cipher suite.
> But Yes, the server may have deterministic knowledge that in 
> the pool of clients it serves (or for the particular service 
> it provides) either all clients, or a subgroup of the clients 
> that uses a particular cipher suite, in fact can handle Hash Z.

So you're assuming the existence of some off-line (outside TLS)
negotiation capability (either between the hosts, or their 
administrators) to exchange information about what the 
implementations actually support?

Given that we have the necessary functionality in TLS itself,
why would you want to do that? (And if you do, would this extend
to other parts of TLS as well -- e.g. allow server to select
a cipher suite that the client didn't offer, if it has this
"deterministic knowledge"?)

Best regards,
Pasi

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 13 Dec 2007 22:33:39 +0000

In, line

Stefan Santesson
Senior Program Manager

> From: Eric Rescorla [mailto:[email-masked]]
> Sent: den 12 december 2007 15:06
> To: Stefan Santesson
> Cc: [email-masked]; [email-masked]
> Subject: Re: [TLS] RE: WGLC - Stepping up Hash
>

Not as I see it. If the server chooses to use a better hash than SHA-1, it MUST inform the client of this requirement. As to knowing the capacity, the hash in the finished message is already bound to the PRF defined by the ciphersuite. So the Server can be assured of this capacity of the client without it being explicitly stated in the client hello extension. Why is this so much harder for key and certificate exchange messages.

> created some new protocol that happens to just look a lot

The server should never force the client to sign or validate anything that is not supported by the selected cipher suite.
But what if the server and client agrees to CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, but the client does not provide a signature_algorithms extension?
Following the current definition in the Server Key exchange message, the server would be forced to specify SHA-1 as hash algorithm. That does not make any sense to me.

> offer the extension in these special cases.

It is not. But what if it doesn't. This should clearly be the implementation goal for all clients. However, theory and practice don't always meet and we should not create rules that prevents the server from safely step up the security level in case the client fail to send this info. Or we should REQUIRE the client to provide this extension in these cases (e.g. for some cipher suites). The client is after all not required to provide this in the current spec.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Dec 2007 14:50:21 -0800

At Thu, 13 Dec 2007 22:33:39 +0000,
Stefan Santesson wrote:
> Not as I see it. If the server chooses to use a better hash than
> SHA-1, it MUST inform the client of this requirement.

Yes, I'm talking about explicit signalling of capabilities.

> As to knowing
> the capacity, the hash in the finished message is already bound to
> the PRF defined by the ciphersuite. So the Server can be assured of
> this capacity of the client without it being explicitly stated in
> the client hello extension.

Yes, but the capabilities of the implementation in terms of HMAC
and the cipher suite may or may not be the same as the capabilities
available for certificate validation. That's why we have a separate
extension to indicate those capabilities.

> Why is this so much harder for key and
> certificate exchange messages.

It's not "harder", it's just not how this is negotiated in TLS 1.2,
for the reasons indicated above.

> The server should never force the client to sign or validate
> anything that is not supported by the selected cipher suite.  But
> what if the server and client agrees to CipherSuite
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, but the client does not
> provide a signature_algorithms extension?  Following the current
> definition in the Server Key exchange message, the server would be
> forced to specify SHA-1 as hash algorithm. That does not make any
> sense to me.

I'm sorry it doesn't make sense to you. I consider it quite
reasonable. What doesn't make sense is for the server to 
assume the client supports a given digest when the client
has explicitly declined to inform the server that it in fact
does so.

> It is not. But what if it doesn't.

If it doesn't, what the server does is clear: it assumes that the client
knows SHA-1. Again, I don't see what the problem is here.

> should clearly be the implementation goal for all clients. However,
> theory and practice don't always meet and we should not create rules
> that prevents the server from safely step up the security level in
> case the client fail to send this info. 

I don't agree. This isn't about stepping up or stepping down. It's
about the server choosing to use cryptographic algorithms that
the client didn't offer. That creates interop problems.

> Or we should REQUIRE the
> client to provide this extension in these cases (e.g. for some
> cipher suites).

Again, what the client supports for certificate verification and
what it supports in the cipher suite are orthogonal issues.

-Ekr

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 13 Dec 2007 23:02:05 +0000

OK Eric,

I won't take this argument any further. At least I have assured myself that you have considered this issue from all angles.
Getting this document through the process is more important.

Stefan Santesson
Senior Program Manager

> Sent: den 13 december 2007 14:50
> To: Stefan Santesson
> Cc: Eric Rescorla; [email-masked]; [email-masked]
> that

---

From: <[email-masked]>
Date: Fri, 14 Dec 2007 09:34:08 +0200

Stefan Santesson wrote:

> It is not. But what if it doesn't. This should clearly be the 
> implementation goal for all clients. However, theory and 
> practice don't always meet and we should not create rules 
> that prevents the server from safely step up the security 
> level in case the client fail to send this info. Or we should 
> REQUIRE the client to provide this extension in these cases 
> (e.g. for some cipher suites). The client is after all not 
> required to provide this in the current spec.

I think the source of this confusion is the sentence "Clients 
SHOULD send this extension if they support any hash algorithm 
other than SHA-1" (in Section 7.4.1.4.1)

This is not quite correct. It should say something along
the lines:

  "If the client supports other hash and signature 
  algorithms (than the defaults listed in this section), 
  and it is willing to use them for verifying messages 
  sent by server (server certificates and server key exchange), 
  it MUST send the signature_algorithms extension listing
  the algorithms it is willing to accept."

(IMHO this is what the current spec implicitly means.)

Best regards,
Pasi

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 14 Dec 2007 11:21:06 -0500

I agree with Martin Rex that permitting implicit (meta-knowledge-based)
signaling could inhibit implementation of proper signaling,
and that the interoperability disadvantage (when meta-knowledge
turns out to be wrong) outweighs any advantage of being able
to use step-up hash with clients that support additional hash
algorithms but do not send the extension.  Such clients,
if there are any, should be fixed.

The spec should be modified along the lines suggested below
to remove ambiguity from the requirement for explicit
signaling.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, December 14, 2007 2:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [TLS] RE: WGLC - Stepping up Hash

Best regards,
Pasi