Subject: [websec] Another way to look at announcing strict security

From: Paul Hoffman <[email-masked]>
Date: Tue, 30 Nov 2010 14:36:02 -0800

Greetings again. As I mentioned briefly in my presentation in Beijing, there are some assumptions that various people in this discussion make that don't jibe with the assumptions that others make. The HSTS draft is based on one set of assumptions, but many of the commenters come from a different set of assumptions, and the two sides are talking past each other.

I have just submitted the following:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>	Title           : Specifying That a Server Supports TLS
>	Author(s)       : P. Hoffman
>	Filename        : draft-hoffman-server-has-tls-00.txt
>	Pages           : 7
>	Date            : 2010-11-30
>
>A server that hosts applications that can be run with or without TLS
>may want to communicate with clients whether the server is hosting an
>application only using TLS or also hosting the application without
>TLS.  Doing so tells clients that try using TLS but fail to set up a
>TLS session whether or not they should even try to set up an insecure
>session with the server.  This document describes the use cases for
>this type of communication and a secure method for communicating that
>information.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-hoffman-server-has-tls-00.txt

Section 2 is explicitly meant to cover all the assumptions that I have seen so far, and the semantics of the protocol is meant to allow everyone to state what they are doing. If people agree that the assumptions and semantics in my draft cover all the desired cases, I would be happy to share them with the HSTS draft.

Note again that I am *not* proposing that the DNS-based solution be taken instead of the in-band solution for HTTP that the HSTS draft proposes. I think that both have good reasons for existing at the same time. I also hope that the two could have the same semantics so that if a company who wants to announce that it supports secure-only HTTP, it can do so both in the DNS (before someone has connected for the first time) and in HTTP (for those users who do not yet have DNSSEC enabled).

--Paul Hoffman, Director
--VPN Consortium

---

From: =JeffH <[email-masked]>
Date: Tue, 30 Nov 2010 18:40:55 -0800

> Greetings again. As I mentioned briefly in my presentation in Beijing, there
 > are some assumptions that various people in this discussion make that don't
 > jibe with the assumptions that others make. The HSTS draft is based on one
 > set of assumptions, but many of the commenters come from a different set of
 > assumptions, and the two sides are talking past each other.
 >
 >> A server that hosts applications that can be run with or without TLS may
 >> want to communicate with clients whether the server is hosting an
 >> application only using TLS or also hosting the application without TLS.
 >> Doing so tells clients that try using TLS but fail to set up a TLS session
 >> whether or not they should even try to set up an insecure session with the
 >> server.  This document describes the use cases for this type of
 >> communication and a secure method for communicating that information.
 >>

Interesting, thanks for writing & posting this.

 > Section 2 is explicitly meant to cover all the assumptions that I have seen
 > so far, and the semantics of the protocol is meant to allow everyone to
 > state what they are doing. If people agree that the assumptions and
 > semantics in my draft cover all the desired cases, I would be happy to share
 > them with the HSTS draft.

Without commenting on the specifics of the proposed RR name and contents and 
syntax, that section 2 does look overall useful, I'll see how it might be 
leveraged in -strict-transport-sec.

 > Note again that I am *not* proposing that the DNS-based solution be taken
 > instead of the in-band solution for HTTP that the HSTS draft proposes. I
 > think that both have good reasons for existing at the same time.

agreed.

 > I also hope
 > that the two could have the same semantics so that if a company who wants to
 > announce that it supports secure-only HTTP, it can do so both in the DNS
 > (before someone has connected for the first time) and in HTTP (for those
 > users who do not yet have DNSSEC enabled).

Yes, acknowledging and facilitating such deployment overlaps (both on server 
and client sides) will be important -- not the least because they'll be 
long-lasting.

=JeffH