Subject: [keyassure] Binding to full TLS encapsulation or STARTTLS

From: Matt McCutchen <[email-masked]>
Date: Sun, 13 Feb 2011 13:15:10 -0500

I realized that TLSA as we are currently discussing does not bind keys
to the use of full TLS encapsulation or STARTTLS.  I'm thinking this is
OK because it would be pretty ridiculous to multiplex different services
based on the use of full encapsulation or STARTTLS, and clients
generally do not ascribe security significance to the use of one or the
other.  E.g., if I bind a key to _3141._tcp.example.com for a service
that uses STARTTLS, I can't think of any scenario in which a client
trying to use full encapsulation would be harmed if a MITM allowed it to
succeed by performing the STARTTLS part directly with the server.  It
might be nice to prevent web browsers from talking to STARTTLS services,
but that would be far from a complete solution to the problem of
browsers being a loose cannon for arbitrary connections, nor is it our
responsibility to solve that problem here.

Sanity check?

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 13 Feb 2011 18:53:47 -0500

That openeth a can of worms.

While it would be nice to be able to simply open a TLS session rather than
start raw and negotiate an upgrade, that is hard to support on the server
side unless the server has separate port assignments for raw and TLS
service.

That works for HTTP, NNTP and a few others. But the IAB and IESG clamped
down on dual port assignments and so that scheme only works in some cases.

HTTPS is not quite the same thing as HTTP with inband upgrade to SSL.

I am not even sure how widely supported the inband upgrade is for HTTP.

Not trying to be difficult here, I have really no good scheme for fixing
this.

On Sun, Feb 13, 2011 at 1:15 PM, Matt McCutchen <[email-masked]>wrote:

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

-- 
Website: http://hallambaker.com/