Subject: [TLS] Re: Interoperability failure caused by CBC block cipher padding

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Dec 2007 18:25:45 +0100

<[email-masked]> writes:

> A while ago, I did some testing on how implementations
> handled this, and presented the results in IETF67. See:
>
> http://www3.ietf.org/proceedings/06nov/slides/tls-3/sld8.htm 
> http://www3.ietf.org/proceedings/06nov/slides/tls-3/sld9.htm

Interesting, thanks for the pointer.

Btw, I wasn't aware of the failure in GnuTLS regarding 'Unknown content
types', and it seems Nikos has fixed this.

> Basically, most implementations seemed to handle this OK.
> Perhaps we could add this to the "implementation pitfalls"
> section, though.

How about adding:

- Do you handle arbitrary pad lengths in GenerBlockCipher (see Section
  6.2.3.2)?

> (i will also try to report this bug to the people responsible
> for fixing this.)

Thanks,
Simon

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

---

From: <[email-masked]>
Date: Thu, 6 Dec 2007 20:00:12 +0200

Simon Josefsson wrote:
> Btw, I wasn't aware of the failure in GnuTLS regarding 
> 'Unknown content types', and it seems Nikos has fixed this.

After the discussion in IETF 67, I wouldn't really call
it a failure. Most people seemed to think that the text
"SHOULD just ignore it" text in TLS 1.0/1.1 was wrong
(and GnuTLS was doing the right thing).

In rfc4346-bis-07 this text is changed to:

   Implementations MUST NOT send record types not defined in 
   this document unless negotiated by some extension.  If a 
   TLS implementation receives an unexpected record type, it 
   MUST send an unexpected_message alert.

Best regards,
Pasi

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 10 Dec 2007 16:04:16 +0100

<[email-masked]> writes:

> it a failure.

Ah.  The "fail" sent a slightly different message. ;)

> Most people seemed to think that the text "SHOULD just ignore it" text
> in TLS 1.0/1.1 was wrong (and GnuTLS was doing the right thing).
>

Interesting, so we have reverted our change.

However, this brings up the questions whether such text is intended to
only describe what a conforming TLS 1.2 implementation should do, or
whether it is also intended to update what a TLS 1.0/1.1 implementation
should do?  Right now GnuTLS will refuse unexpected record types
regardless of the negotiated version.

/Simon

---

From: <[email-masked]>
Date: Wed, 12 Dec 2007 09:21:55 +0200

Simon Josefsson wrote:

> However, this brings up the questions whether such text is intended
> to only describe what a conforming TLS 1.2 implementation should do,
> or whether it is also intended to update what a TLS 1.0/1.1
> implementation should do?  Right now GnuTLS will refuse unexpected
> record types regardless of the negotiated version.

Except when explicitly noted so, nothing in the TLS 1.2 spec is
intended to change what implementations do when TLS 1.0/1.1 is
negotiated.

(The possible exceptions are Appendix E and Section 7.4.7.1, which
apply to implementations that do both TLS 1.2 and earlier versions.)

However, for this particular issue (unexpected record types),
it should be noted that someone implementing RFC 2246/4346 will
never send unexpected record types -- and there are no specs that
expect them to be ignored -- so if you receive them, something
is clearly wrong, and refusing them seems right to me.

Best regards,
Pasi