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

[Stefan Santesson <stefans@xxxxxxxxxxxxx>]

For the record, I'm fine with this change proposal.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Kemp, David P. [mailto:DPKemp@xxxxxxxxxxxxxx]
> Sent: den 14 december 2007 17:21
> To: tls@xxxxxxxx
> Subject: RE: [TLS] RE: WGLC - Stepping up Hash
>
> 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


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