Subject: [ietf-tls] Re: draft-ietf-tls-wireless-00.txt

From: Eric Murray <[email-masked]>
Date: Tue, 5 Jun 2001 13:12:14 -0700

On Tue, Jun 05, 2001 at 04:21:15AM -0400, Simon Blake-Wilson wrote:
> Hi Eric,
> 
> On the MAC truncation issue, I think the MAC.type field may well be useful going
> forward. As a client, I might prefer not to knowingly weaken the MAC by
> truncation, and thus be prepared to use 80 bit SHA1 but not 80 bit SHA2. Make
> sense?

Yea.

> The text in the draft was meant to clarify what clients and servers do if
> something untoward happens ... here's the text:
> 
> Servers receiving MAC truncation negotiation requests requesting values
> other than the allowed values, MUST abort the handshake. Similarly
> clients receiving MAC truncation negotiation responses that differ from
> the values they suggested, or that do not match the established cipher
> suite, MUST abort the handshake.
> 
> Could we address this issue by clarifying this text, and if so, how?

That text is fine, but there needs to be something more that explains
what the interaction between the MAC_type field and the hash in the chosen
ciphersuite is.

I can think of a couple different ways to do it:

1. If one or more truncated_MAC options are sent and the server wants to do
MAC truncation, the server must choose a truncated_MAC from the list
provided by the client that specifies a MACAlgorithm which matches
the hash in the pending ciphersuite (SecurityParameters.mac_algorithm).

2. If one or more truncated_MAC options are sent and the server wants to do
MAC truncation, the server must choose a truncated_MAC from the list
provided by the client, and the hash in the pending ciphersuite is changed
to the MACAlgorithm in the chosen truncated_MAC option.

I think that #2 is pretty confusing-- the hash gets renegotiated
based on the option, which seems architectually wrong to me. 
#1 is simpler, but still requires the server to
correlate the hash algorithms in the truncated_MAC option(s)
against the SecurityParameters.mac_algorithm.
The structure of the Ciphersuite specs don't make for easily
determining which ones are SHA and which are MD5 (implementations
will need another lookup table).

My suggestion (simply using the hash that's specified in the pending
ciphersuite) would still allow a client to spec truncation to 80 bits
for sha1 and not for sha2-- but only by sending either sha1 ciphersuites
and a truncated_MAC option for truncation to 80 bits, or sha2 ciphersuites
and no truncated_MAC option (or one for more bits if the client
feels that's what's secure).

That's not exactly straightforward either.

#1 is my preferered option given that it's harder to shoot oneself
in the foot with it.

Eric

> 
> Best regards. Simon
> 
> 
> 
> 
> 
> Eric Murray <[email-masked]> on 06/04/2001 03:31:45 PM
> 
> Please respond to "IETF Transport Layer Security WG"
>       <[email-masked]>
> 
> To:   "IETF Transport Layer Security WG" <[email-masked]>
> cc:    (bcc: Simon Blake-Wilson/Certicom)
> 
> Subject:  [ietf-tls] draft-ietf-tls-wireless-00.txt
> 
> 
> 
> 
> 
> 
> 
> What's the status of draft-ietf-tls-wireless-00.txt?  It's recently
> expired, but various people here on the TLS list have implied that there
> will be a revised version out soon.
> 
> I'm writing an I-D to propose using the generic extension mechanisim
> from draft-ietf-tls-wireless-00.txt to allow negotiation of a simpler
> PRF function, and I'd like to refer to draft-ietf-tls-wireless-00.txt
> or its successor.
> 
> 4
> 
> 
> Also, I've found a small potential problem in draft-ietf-tls-wireless-00.txt.
> Section 3.5 (truncated MACs) specifies the following in the "unknown_extensions"
> field:
> 
>           MACTruncation MACTruncations<0..2^8-1>;
> 
>           struct {
>               MACAlgorithm mac_type;
>               uint16 trucation_size_in_bits
>           } MACTruncation;
> 
>           enum { null(0), md5(1), sha1(2), (255) } MACAlgorithm;
> 
> What's potentially confusing is the MAC specification... what happens
> if sha1 is specified in MACTruncation and the pending ciphersuite is
> say TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5?  Would md5 or sha1 be used?
> Or should MACTruncation.MAC_type always match the hash algorithim in
> the pending ciphersuite?
> 
> Unless there's a reason why MACTruncation.MAC_type is there, I'd
> suggest dropping it and always using the hash that's been negotiated
> as part of the ciphersuite.
> 
> 
> 
> Eric
> 
> ---
> You are currently subscribed to ietf-tls as: [email-masked]
> To unsubscribe send a blank email to [email-masked]
> 
> 
> 
> 
> 
> 
> 
> ---
> You are currently subscribed to ietf-tls as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]