Subject: [TLS] Re: Updated TLS ID (certificate restrictions #57)

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Nov 2007 09:06:06 -0800

At Wed, 31 Oct 2007 17:24:59 +0200,
<[email-masked]> wrote:
At Wed, 31 Oct 2007 17:24:59 +0200,
<[email-masked]> wrote:
> 
> Eric Rescorla wrote:
> 
> > The changes list is:
> > - Redid the hash function advertisements for CertificateRequest
> >   and the client-side extension. They are now pairs of
> >   hash/signature and the semantics are clearly defined for
> >   all uses of signatures (hopefully). [Issue 41]
> <snip>
> > - Cleaned up certificate text in 7.4.2 and 7.4.6 [Issue 57]
> 
> This looks pretty good. In Section 7.4.2, I think there's
> still some room for simplification. Currently it says:
> 
>    If no "signature_algorithms" extension is present, the end-entity
>    certificate MUST be signed as follows:
> 
>       Key Exchange Alg.  Signature Algorithm Used by Issuer
> 
>       RSA                RSA (RSASSA-PKCS1-v1_5)
>       DHE_RSA
>       DH_RSA
>       RSA_PSK
>       ECDH_RSA
>       ECDHE_RSA
> 
>       DHE_DSS            DSA
>       DH_DSS
> 
>       ECDH_ECDSA         ECDSA
>       ECDHE_ECDSA
> 
> I think it would be simpler to specify the default behavior
> in one place, and not to make it ciphersuite-dependent.
> E.g. "if the client does not send signature_algorithms,
> behave as if rsa+sha1 had been sent". Or we could just require
> everyone to send signature_algorithms.

So, I see where you're going with this, but I'm concerned about
making it (say) RSA-SHA1 because that would potentially make
currently compliant configurations noncompliant (e.g., if you
had a pure DSA-DH shop). 

As for requiring signature_algorithms, I'm concerned about requring
extensions. I think we're getting close to the point where it's
definitely safe, but I'm not sure we're there yet.

-Ekr

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

---

From: <[email-masked]>
Date: Tue, 13 Nov 2007 08:08:46 +0200

Eric Rescorla wrote:

> currently compliant configurations noncompliant (e.g., if you had 
> a pure DSA-DH shop).

There are currently *no* compliant TLS 1.2 configurations (early
implementations of e.g. -04 draft won't be compatible with the
next draft version anyway), and we aren't changing the behavior 
when TLS 1.0/1.1 is negotiated.

(And it doesn't have to be RSA-SHA1; but IMHO something along
the lines "if the extension was not sent, behave as if XYZ had
been sent" would be simpler than the current text.)

> definitely safe, but I'm not sure we're there yet.

I'm not sure if we're at a point where it would be definitely
safe to propose TLS 1.2 :-) (without automatic fallback to 
SSLv3/TLS 1.0 if the negotation fails)

But you won't get full signature algorithm agility without extensions
anyway -- I just think we probably don't want to have a half-way
solution (with extra complexity) for folks who don't want to use
extensions.

Best regards,
Pasi

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 13 Nov 2007 10:27:24 -0800

> been sent" would be simpler than the current text.)

Sorry, what I mean is:
If you have TLS 1.1 server with a DSS cert, then you can currently run
DSS_DHE. It should be the case that if you switch to TLS 1.2, this
continues to work, which means that the implied signature_algorithms
need to permit DSA/SHA-1 in this case.

So, I think the right thing is: assume that SHA-1 is permitted
and that you can use whatever signature algorithm is specified
in the cipher suite.

-Ekr

---

From: <[email-masked]>
Date: Wed, 14 Nov 2007 10:54:19 +0200

Eric Rescorla wrote:

> Sorry, what I mean is: If you have TLS 1.1 server with a DSS cert,
> then you can currently run DSS_DHE. It should be the case that if
> you switch to TLS 1.2, this continues to work, which means that the
> implied signature_algorithms need to permit DSA/SHA-1 in this case.

This means we'd have two different ways to specify supported
signature algorithms: the extension and the cipher suite.
IMHO this is unnecessarily complicated -- if you switch to TLS 1.2,
your new implementation will simply have to support the extension.

Otherwise, we have to specify how the two mechanisms interact.

> and that you can use whatever signature algorithm is specified

Well... even in that case, I'd prefer describing this 
as a default value for signature_algorithms extension in 
Section 7.4.1.4.1 (rather than mixing this in with the
certificate selection text).

E.g. something along these lines:

   If the client does not send the signature_algorithms 
   extension, the server will assume the following:

   o  If the negotiated key exchange algorithm is one
      of (RSA, DHE_RSA, DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), 
      behave as if client had sent the value (sha1,rsa).
    
   o  If the negotiated key exchange algorithm is one of 
      (DHE_DSS, DH_DSS), behave as if the client had sent the
      value (sha1,dsa).

   o  If the negotiated key exchnage algorithm is one of 
      (ECDH_ECDSA, ECDHE_ECDSA), behave as if the client had
      sent value (sha1,ecdsa).

(BTW, the SignatureAlgorithm enum is missing "ecdsa").

Best regards,
Pasi