RE: [TLS] RE: WGLC - Stepping up Hash

["Kemp, David P." <DPKemp@xxxxxxxxxxxxxx>]

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: Pasi.Eronen@xxxxxxxxx [mailto:Pasi.Eronen@xxxxxxxxx] 
Sent: Friday, December 14, 2007 2:34 AM
To: stefans@xxxxxxxxxxxxx
Cc: tls@xxxxxxxx
Subject: RE: [TLS] RE: WGLC - Stepping up Hash

Stefan Santesson wrote:

> > I don't understand why it's a problem to simply have the client
> > 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.

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


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


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