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

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 <matt@mattmccutchen.net>wrote:

> 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
>
>
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure
>

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