Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00

From: Joseph Salowey <[email-masked]>
Date: Sun, 1 Mar 2015 20:04:07 -0800

There is consensus to move forward with this document.  The authors have
published a revision, draft-ietf-tls-sslv3-diediedie-02, which covers the
comments raised on during the last call .   This revision will be forwarded
to the IESG for publication.

On Fri, Jan 23, 2015 at 11:29 AM, Joseph Salowey <[email-masked]> wrote:

> This is a working group last call for draft-ietf-tls-sslv3-diediedie-00.
> Please reply to the TLS working group list with an indication of whether or
> not the draft is ready for publication and any other comments you may
> have.  Please respond by February 16, 2015.
>
> Thanks,
>
> S & J
>

---

From: Erik Nygren <[email-masked]>
Date: Mon, 2 Mar 2015 12:44:00 -0500

Is it worth adding in a note to section 4 (Limited Capabilities) of:

* Server Name Indication to enable virtual hosting of multiple hosts with
independent certificates on a single IP address

?

I'm not sure if it's critical enough to hold up last-call?  It is another
major down-side of the lack of extension support in SSLv3 from a
deploy-ability perspective.

      Erik

On Sun, Mar 1, 2015 at 11:04 PM, Joseph Salowey <[email-masked]> wrote:

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 2 Mar 2015 10:43:04 -0800

> deploy-ability perspective.

Each of us feels a different pain, don't we?

We could continue to list the many ways, but I think that we have
enough justification without the addition.  If a chance comes up, I
think that I will add "Server Name Indication [RFC6066]" to the list
of missing features though.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 2 Mar 2015 12:55:39 -0800

I am going to continue to move forward with the publication request.  I
think we will have opportunity to add this later in the process.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 2 Mar 2015 13:45:09 -0800

> think we will have opportunity to add this later in the process.

Indeed.  I'll prepare a PR for it and merge it if an opportunity
arises.  The IESG has a habit of providing that sort of opportunity.

---

From: [email-masked] (Martin Rex)
Date: Tue, 3 Mar 2015 00:24:30 +0100 (CET)

> deploy-ability perspective.

Your notion seems to be based on a urban legend.

SSLv3 (the protocol), in the final, after-the-fact publication
of November 18, 1996 (which the IETF failed to publish for 15 years,
but finally did as https://tools.ietf.org/html/rfc6106 ),
has _the_exact_same_ support for extensions as TLSv1.0.

Implementations of SSLv3, however, do not necessarily make use of
that capability.

SNI has only limited value, and provides an additional attack surface, e.g.
  https://bh.ht.vc/vhost_confusion.pdf

Personally, I'm much more concerned about newer software that breaks
horribly when no TLS extension SNI is present in the ClientHello,
such as Microsoft ADFS 2012.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Mon, 2 Mar 2015 17:57:10 -0800

> Implementations of SSLv3, however, do not necessarily make use of

Actually, the RFC you meant was RFC 6101
(https://tools.ietf.org/html/rfc6101). The word extension doesn't
appear in the draft, instead all we see is a forward compatibility
note, stating that extra data may appear after the hello.

It's true that RFC 2246 doesn't mandate extension support either. But
RFC 3546 defines extensions for TLS 1.0, not SSLv3.0. Of course, you
could say that SSL v3.0 extensions should be supported the same way as
TLS 1.0. But there's no indication that this is actually what the
documents mean, or how servers and clients are actually implemented.
>   https://bh.ht.vc/vhost_confusion.pdf

Multitenancy is incredibly common, especially given IPv4 exhaustion.
Absent SNI, there is no good way for CDNs to function.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin