Subject: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension

From: [email-masked]
Date: Wed, 21 Oct 2015 13:43:20 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        RFC 7685

        Title:      A Transport Layer Security (TLS) 
                    ClientHello Padding Extension 
        Author:     A. Langley
        Status:     Standards Track
        Stream:     IETF
        Date:       October 2015
        Mailbox:    [email-masked]
        Pages:      4
        Characters: 7034
        Updates:    RFC 5246

        I-D Tag:    draft-ietf-tls-padding-04.txt

        URL:        https://www.rfc-editor.org/info/rfc7685

        DOI:        http://dx.doi.org/10.17487/RFC7685

This memo describes a Transport Layer Security (TLS) extension that
can be used to pad ClientHello messages to a desired size.

This document is a product of the Transport Layer Security Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Oct 2015 14:04:03 -0700

>                     ClientHello Padding Extension

That took longer than I expected.  Nice work.

---

From: Dave Garrett <[email-masked]>
Date: Wed, 21 Oct 2015 20:17:31 -0400

Congrats on releasing an RFC that has day one 100% server support. :p

Dave

---

From: Hubert Kario <[email-masked]>
Date: Thu, 29 Oct 2015 15:07:58 +0100

> Congrats on releasing an RFC that has day one 100% server support. :p

oh, I'm sure there's at least one server out there that is intolerant to 
this one specific extension ]:->

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 29 Oct 2015 15:00:04 +0000

> this one specific extension ]:->

When the extension was first enabled in OpenSSL 1.0.1g there were
(and perhaps some are still left unpatched) Cisco IronPort SMTP
servers that could not handle the extension.

A fix was issued promptly, but customers did need to find out about
it and apply it.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Thu, 29 Oct 2015 11:56:27 -0400

> servers that could not handle the extension.

Now I'm just curious: How? Where they essentially just intolerant to _any_ new extension or one of a certain length?

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 29 Oct 2015 16:35:18 +0000

> Now I'm just curious: How? Where they essentially just intolerant to _any_ new extension or one of a certain length?

I think it was the resulting client HELLO length (512+ bytes), but
I don't recall seeing the details explained.

    http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html
    http://openssl.6102.n7.nabble.com/openssl-update-1-0-1f-to-1-0-1g-broke-sendmail-SSL23-GET-SERVER-HELLO-tlsv1-alert-decode-error-td49242.html
    https://www.mail-archive.com/search?l=[email-masked]&q=subject:%22Re%3A+[openssl.org+%233336]+1.0.1g+breaks+IronPORT+SMTP+appliance+%28padding+extension%29%22&o=newest&f=1

If John Foley from Cisco is on this list, perhaps he'll be willing
to elaborate.

-- 
	Viktor.