Subject: [DNSOP] Declaring HTTPS mandatory in the DNS

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 19 Nov 2012 11:18:34 +0100

I vaguely remember that there was an Internet-Draft about declaring,
in the DNS, that a HTTP server MUST be accessed only by HTTPS. But I
cannot find it, either with the Datatracker or with Google. Any
pointer?

(I know about draft-ietf-websec-strict-transport-sec, which is a HTTP
solution, I'm looking for a DNS one.)

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 19 Nov 2012 07:32:55 -0500

> cannot find it, either with the Datatracker or with Google. Any
The closest you're likely to find that is in 
http://tools.ietf.org/id/draft-jennings-http-srv-05.txt draft (expired), 
where an HTTPS SRV record might be published for a given site, but no 
equivalent HTTP SRV record. That would implicitly be a "declaration" 
that only HTTPS was supported for the site. Honestly though, I foresee 
that even if SRV record lookup is adopted by the browser community, for 
many years after that, browsers will continue to fall back to 
non-SRV-based connection methods. So the absence of an HTTP SRV record 
is not likely to prevent many HTTP connection attempts in the short to 
medium term.
> solution, I'm looking for a DNS one.)
Despite what the Wikipedia page says, that ID doesn't really define a 
"declaration" that HTTPS is preferred over HTTP as the transport to be 
used for accessing a given web host. The use of HTTPS is *assumed*, 
throughout the ID, in order for the mechanisms defined therein to occur, 
e.g. the use of the special "Strict-Transport-Security" HTTP header. The 
only major reference to non-secure HTTP is a generic recommendation 
("SHOULD") to perform a 301 redirect from HTTP to HTTPS (which hardly 
needs an ID callout, since it's _de_facto_ standard anyway). The ID does 
make reference to a possible "HSTS Pre-Loaded List", i.e. a list of 
sites that a browser would know _a_priori_ to implement HSTS, but there 
is no automated mechanism defined to publish/distribute that list, other 
than a vague suggestion (Section 12.3) that site owners and browser 
implementors get together to bake the list into the software "at the 
factory".

                     - Kevin

---

From: Scott Schmit <[email-masked]>
Date: Mon, 19 Nov 2012 09:05:43 -0500

> cannot find it, either with the Datatracker or with Google. Any

Perhaps you're thinking of this expired draft: draft-hoffman-server-has-tls?

-- 
Scott Schmit

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 19 Nov 2012 15:41:32 +0100

On Mon, Nov 19, 2012 at 09:05:43AM -0500,
 Scott Schmit <[email-masked]> wrote 

> Perhaps you're thinking of this expired draft: draft-hoffman-server-has-tls?

Exactly! Thanks. This I-D is not HTTPS-specific, which may explain why
I did not find it.

Someone also suggested this proposal (not an I-D):

http://www.circleid.com/posts/20090105_problem_with_https_ssl_md5/

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 19 Nov 2012 10:08:21 -0500

> http://www.circleid.com/posts/20090105_problem_with_https_ssl_md5/
It should be noted that the section of the original article recommending 
a custom DNS record be "quickly" standardized through the IETF process, 
and adopted, was actually struck out after feedback by Robert Graham:

    As Robert Graham, co-founder and CEO of Erratasec
    <http://www.erratasec.com/> pointed out, I have the implementation
    process backwards because implementation has always come before
    standardization on the Internet. I must have been asleep writing
    that last paragraph because I should already know better.

        */Robert Graham:/*/What made the Internet different from all the
        other competing internetworks of the 1980s was that people would
        implement something first, then standardize it. OSI failed
        because standards led implementations./

    Either Microsoft or Mozilla should just implement something, and
    document the DNS format that they will accept. Standards bodies can
    catch up later.

I think this is probably wise advice, although there is nothing wrong 
with getting Microsoft, Mozilla and/or Google involved early in the 
standardization process...

                                         - Kevin

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Nov 2012 07:36:20 -0800

> Exactly! Thanks. This I-D is not HTTPS-specific, which may explain why

Y'all forget that think that security is valuable for things other than the web. :-)

The draft has expired because there was little interest in it, and it causes weird interactions with HSTS from the websec WG.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Nov 2012 13:47:00 -0500 (EST)

> The draft has expired because there was little interest in it, and it causes weird interactions with HSTS from the websec WG.

That will probably lead to people using the TLSA record as a pointer to
"do not connect without TLS". Which I believe people who wanted HASTLS
did not like?

(as HSTS does not protect you from attacks from sites you've never
  visited before from a trusted network)

Paul

---

From: Tony Finch <[email-masked]>
Date: Wed, 21 Nov 2012 14:00:56 +0000

Paul Wouters <[email-masked]> wrote:
> "do not connect without TLS".

I wrote that requirement into my DANE for email drafts.
http://tools.ietf.org/html/draft-fanf-dane-smtp-04#section-3.2
http://tools.ietf.org/html/draft-fanf-dane-mua-00#section-3

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: dgq2011 <[email-masked]>
Date: Fri, 23 Nov 2012 11:53:39 +0800

Basically, the draft (draft-hoffman-server-has-tls) provides a mechanism by which the server tells the client which is insecure/secure port. An idea suddenly coming into my mind is why not integrate such mechanism with SRV [RFC2782]? The format of the SRV RR is like this: _Service._Proto.Name TTL Class SRV Priority Weight Port Target. Just add one field to indicate the security property of the port (namely to indicate whether the port is secure or not) and then most of the work is done. Forgive me if something obvious is missed!

Guangqing Deng

From: Paul Wouters
Date: 2012-11-20 02:47
To: Paul Hoffman
CC: dnsop
Subject: Re: [DNSOP] Declaring HTTPS mandatory in the DNS

Paul
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop