Subject: [dnsext] A custom DNS record for mandatory SSL/TLS

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 6 Jan 2009 10:29:49 +0100

[I know that IETF WG are not fond of press articles related to their
work but this one is really related to the new RFC 5395 process.]

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

Old version:

> The Internet standards bodies needs to quickly adopt and standardize
> a custom DNS record for mandatory SSL/TLS. Then Microsoft, Mozilla,
> Apple, or Google need to implement the changes on their web browser
> products to enforce the strong SSL policies.

New version:

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Danny Mayer <[email-masked]>
Date: Tue, 06 Jan 2009 07:57:54 -0500

>> document the DNS format that they will accept. Standards bodies can

Then they should also implement usage of SRV types as well while they
are at it.

Danny

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 05 Jan 2009 18:25:41 -0800

Stephane and all,

  This actually nothing really new.  There has been a known problem
with MD5 TLS for some time now and significantly discussed on the
ABA security forum.  The fact that the IETF has for whatever reason
to ignore this problem is a matter of some reasonable concern.

  Relying entirely on the IETF for standards is and has been a very
questionable paradign for more than a decade.  Yet the IETF usually
does an execellent job.

> > document the DNS format that they will accept. Standards bodies can

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 05 Jan 2009 18:30:12 -0800

Danny and all,

  Good point, IMO!

Regards,

---

From: "Adam Langley" <[email-masked]>
Date: Tue, 6 Jan 2009 18:07:40 -0800

> Then they should also implement usage of SRV types as well while they

The inability to make multiple requests in a single DNS packet is
troublesome for SRV records since that implies multiple requests for
each hostname. Also, correct support requires waiting for the SRV
request to complete. Since they are much less likely to be cached
close to the resolver, early users pay a latency price too.

This (HTTPS) proposal also means making multiple requests, although
one would hope that some "HTTPS required" record would have a very
high TTL. Also, requesting non A/AAAA records is a problem on many
platforms due to missing library support.

I think the proposer missed a trick here. The HTTPS required flag
could be carried as an optional header in HTTP(S) replies. This means
that the first ever request may be carried insecurely, but from then
on, the user would be protected. The DNS proposal also has this
property since a MITM attack on the first access could remove the flag
from any DNS reply also.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Jan 2009 09:30:06 +0100

On Tue, Jan 06, 2009 at 06:07:40PM -0800,
 Adam Langley <[email-masked]> wrote 
 a message of 26 lines which said:

> Since they are much less likely to be cached close to the resolver,

Why? You mean "today, because there are few SRV requestors and so the
early adopters will suffer"?

> Also, requesting non A/AAAA records is a problem on many platforms
> due to missing library support.

No, only MS-Windows. That's not "many platforms".

> The HTTPS required flag could be carried as an optional header in
> HTTP(S) replies. This means that the first ever request may be
> carried insecurely, but from then on, the user would be protected.

Isn't there an obvious downgrade attack here? What would prevent the
bad guy to modify the HTTP reply to say "no HTTPS required"?

> The DNS proposal also has this property since a MITM attack on the
> first access could remove the flag from any DNS reply also.

Unless you have DNSSEC. We now need a "DNSSEC required" flag in RFC
3912 output to check that, if there is no DNSSEC signature, it is on
purpose. Next step, whois over TLS :-)

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 07 Jan 2009 10:10:28 +0100

> Then they should also implement usage of SRV types as well while they

...which, unless there is now an rfc that specifies it, is a SHOULD NOT in the
SRV rfc. This may be the case, but i'm not aware of it. That is something
different than
there's-no-spec-(yet)-so-let's-get-something-working-and-then-define-it.

Jelte

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 07 Jan 2009 10:12:06 +0100

> early adopters will suffer"?

/me doesn't see exactly how that would hurt.

Also, something which is 'latency' sensitive as VoIP is using it quite
fine it seems. I have SRV records for SIP, IAX and STUN and next to that
Jabber seems to enjoy it quite well too. Seeing that gtalk is seemingly
quite popular I think it is quite well deployed already and not many
people are feeling this hurt.

> No, only MS-Windows. That's not "many platforms".

That is strange, I can perfectly manage to do that with the standard
Windows API, which indeed is different from the *nix APIs and that tends
to confuse *nix coders a bit it seems because they tend to think that is
the only way one can do it, Windows is just different, but you can wrap
around that to make it back a bit into standard-*nix style ;)

From the comment in AICCU's resolver.c:

/*
 * Windows Resolver Code, as per:
 *
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dns/dns/dnsquery.asp
 * http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B831226
 */

That is all there is to it, for the actual implementation, just check
the first google hit I found which displays the source:
http://aiccu.sourcearchive.com/documentation/20070115-1/resolver_8c-source.html
or http://www.sixxs.net/tools/aiccu/ for the full normal source text
(resolver.c is where it is at, which you can nick from there as it is
BSD licensed etc... it is not an async resolver, but Windows has other
APIs that do allow that, see above URLs for more on that)

Just in case, as I never actually did a SRV record there:
http://msdn.microsoft.com/en-us/library/cc982162(VS.85).aspx
lists at least:

DNS_TYPE_SIG 0x0018
DNS_TYPE_KEY 0x0019
DNS_TYPE_NXT 0x001e
DNS_TYPE_SRV 0x0021
DNS_TYPE_TKEY 0x00f9
DNS_TYPE_TSIG 0x00fa

Thus I am pretty sure that it supports them. The question of course
being a bit which versions of Windows understands which versions of
those records.

Any other problems there? :)

{well, yes actually: those **** DNS caches that simply drop AAAA queries
and those that cut-off, ignore or drop large TXT queries as they don't
do EDNS0.... grmbl}

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 07 Jan 2009 10:33:20 +0100

To continue this subject a bit from a different angle...

One can already store the following in DNS to indicate where a service
lives:

$ORIGIN example.com.
_http._tcp     PTR _https._tcp
_https_._tcp   SRV 0 100 443 www1
_https_._tcp   SRV 0 200 443 www2
_https_._tcp   SRV 0 100 443 www3

Which would effectively tell "the HTTP over TCP service should not be
used, use HTTPS over TCP for that" and "for HTTPS/TCP contact www{123}".

What if we could add a line like we can do for SSHFP:
_https_._tcp   SSHFP   2 1 396ae4c3c3a86e792f153dd386d3384ff14b53cd

but then for a SSL cert fingerprint:
_https_._tcp   SSLFP   xxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

There is RFC4398 which lists the CERT record, but that would mean a full
  cert, which is fine too of course, but just the fingerprint can suffice.

The idea is that, when DNSSEC is deployed (we are talking about
something new here, thus stuff needs to be upgraded anyway ;) that one
can match also see 'hey that fingerprint actually matches the stuff in
DNS, which is secured by DNSSEC' as such giving you a secure backup
verification of the SSL cert.

Even without DNSSEC in place, this at least allows one to have two paths
to the SSL Certificate, as such, if they are not correct one can notify
the user of the discrepancy (default reject with a more difficult/scary
override like in current Firefox CA errors would be better)

For the duration of SSL cert changes one could list two SSLFP's.

As such, we could either have a new SSLFP (or a generic FP record? or
extend/ammend the SSHFP record?) or maybe define at least a document
that describes how this can be done and what exactly the pros and cons
are of this and maybe push a bit for deployment and implementation of
both this concept and the usage of SRV records and DNSSEC.

Good or yet another bad idea? :)

Greets,
 Jeroen

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Jan 2009 11:21:02 +0100

On Wed, Jan 07, 2009 at 10:12:06AM +0100,
 Jeroen Massar <[email-masked]> wrote 
 a message of 92 lines which said:

> Windows API, 

Well, it was discussed at length in some IETF WG like MARID and that's
what the people at Microsoft says, not me.

http://www.ietf.org/mail-archive/web/ietf/current/msg44485.html

Even in this group:

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00865.html

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 07 Jan 2009 12:01:55 +0100

> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00865.html

Might be that those are either 'old' (2006 and 2005) and from what I
read and recall mostly for handling of 'unknown RRs', but the docs
clearly state:

http://msdn.microsoft.com/en-us/library/ms682097(VS.85).aspx
8<---------------------------------------------------------------------------
DNS_SRV_DATA Structure

The DNS_SRV_DATA structure represents a DNS service (SRV) record as
specified in RFC 2782.

[..]

Client Requires: Windows Vista, Windows XP, or Windows 2000 Professional.
Server Requires: Windows Server 2008, Windows Server 2003, or Windows
2000 Server.
Header Declared in Windns.h.
------------------------------------------------------------------------------>8

Thus SRV should thus just work(tm). Not an NT4 indeed, not on Win95 but
I hope that those are not in use anymore ;)

http://msdn.microsoft.com/en-us/library/ms682082(VS.85).aspx indeed
doesn't have a provision for "other" or something thus I would indeed
not be surprised that it can't handle 'other' records as described in
the mails you referenced. Maybe DNS_WIRE_RECORD can be used for it,
though I would not be surprised if wDataLength and wType are just
correct and that it just works either.

But SRV records can definitely be handled (I would almost mod that
resolver.c thingy to test it but have some other things to do ;)

Greets,
 Jeroen

---

From: "Adam Langley" <[email-masked]>
Date: Wed, 7 Jan 2009 10:06:31 -0800

> early adopters will suffer"?

Right,

> No, only MS-Windows. That's not "many platforms".

I'm not sure if you're saying that Windows supports SRV records well,
or if everything else does. If the former, then credit to Microsoft
for making it work. If the latter, then I would disagree.

Although one can certainly use one of several libraries for DNS
resolution (I would recommend evdns, but then I wrote it ;), it's only
a partial solution for platforms with NSS or similar. Users expect
their configs regarding hosts files, LDAP lookups etc to be respected
for name resolution. The system resolver functions, like gethostinfo,
which perform this correctly don't support lookups of arbitrary DNS
RRs. If there's a good solution to this, I don't know it.

> bad guy to modify the HTTP reply to say "no HTTPS required"?

Nothing, but they would have to do it every time. Like SSH, which
binds a name to a key on the first connection, I'm thinking of a
browser side store which would remember that the given hostname
previously requested "HTTPS only" mode. The first time that the user
makes a non-MITMed connection, the latch would be set.

> purpose. Next step, whois over TLS :-)

Although I have high hopes for DNSSEC deployment in 2009, history
suggests that it's best not to assume that DNSSEC exists ;)

AGL

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 07 Jan 2009 19:49:05 +0100

Adam Langley wrote:
[..]

Afaik, one can do SRV lookups on any common platform
(Windows,Linux,*BSD,Solaris,AIX,HPUX etc etc etc). In some of the *nix
cases you might need a custom written resolver indeed but there are
plenty available which can do that for one.

[..]
> makes a non-MITMed connection, the latch would be set.

As you are talking about HTTP, and HTTP is very easy to extend, write a
draft towards the http-ext working group defining a header eg called
"Transport-Mode:" which can have values "HTTP", "HTTPS", "HTTP,HTTPS".
If the header is not there, which would be with every site knowing about
this, then assume "HTTP,HTTPS", if the header is there and states "HTTP"
then assume no HTTPS version exist, but don't cache the header, this
state could be used to visually represent support for this header.

I would suggest adding that when one is receiving that header over HTTP,
that the browser connects to the HTTPS version of the site. If the
browser then receives the header over HTTPS too (and the certs verify
perfectly), that the browser caches the response and indeed never drops
back anymore.

Implementing this in client/servers should be easy as most/every
web-scripting language can set HTTP headers, eg PHP
header("Transport-Mode: HTTPS"); would lock you in.
And clients should already be able to parse headers ;)

The big problem, like usual, is getting clients (Firefox + IE minimum)
to support it, and to get some huge website on board that actually uses it.

The client part can btw most likely be solved already solved by adding a
Firefox Plugin or similar. Having it in the latest-super-duper-secure
version is a better idea though.

Oh and a possible DoS: fake bank.com website including proper MD5-CA'd
cert, send "Transport-Mode: HTTPS" back, this will be cached, user will
never be able to connect to the real bank.com which might not have SSL
on that host. (far fetched, but possible :)

In summary:
1. Write draft
2. Get it published
3. Get it implemented and used
4. Profit

Greets,
 Jeroen

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 8 Jan 2009 13:36:33 -0800

SRV certainly works on Windows since Windows 2000.
 
In fact Win2K makes extensive use of SRV.

________________________________

From: [email-masked] on behalf of Adam Langley
Sent: Wed 1/7/2009 1:06 PM
To: Stephane Bortzmeyer
Cc: [email-masked]
Subject: [dnsext] Re: A custom DNS record for mandatory SSL/TLS

Right,

AGL

--
Adam Langley [email-masked] http://www.imperialviolet.org <http://www.imperialviolet.org/>

---

From: Danny Mayer <[email-masked]>
Date: Thu, 08 Jan 2009 17:30:40 -0500

>> No, only MS-Windows. That's not "many platforms".

This is untrue. Microsoft is probably the foremost user of SRV records
since they use it for Active Directory.

> for making it work. If the latter, then I would disagree.

They do. See above.

Danny

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 9 Jan 2009 11:21:41 +0100

On Thu, Jan 08, 2009 at 05:30:40PM -0500,
 Danny Mayer <[email-masked]> wrote 
 a message of 23 lines which said:

> This is untrue.

This is true. It was about unknown record types, not about SRV (read
the Subject again: a CUSTOM record type). And read the MARID archives,
the statement I repeated was expressed by Microsoft employees.

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 08 Jan 2009 12:09:42 -0800

Stephane and all,

  Stephane is correct here as to substance.  However MS
employees expressing anything of signifigance should wisely
be taken with a large grain of salt...

Regards,

---

From: Danny Mayer <[email-masked]>
Date: Sat, 10 Jan 2009 10:10:00 -0500

> the statement I repeated was expressed by Microsoft employees.

It is true of UNKNOWN record types but I was talking about SRV types.
>From my understanding of how Microsoft implemented things in their DNS
code it would be difficult for their code to implement something to
properly handle types that it knows nothing about.

Disclaimer: I have never seen Microsoft's DNS source code.

Danny

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 16 Jan 2009 23:15:20 -0800

I have seen the source code. They showed it at the MARID group
 
It supports SRV. In fact active directory depends on them.
 
But there is no way to use that server for unknown record types on a prouction system. Yes you can manipulate them into the server. But there is no way to say the unknown RR. The code to save the zone file just drops the data. So the server will reset after a reboot.

From: [email-masked] on behalf of Danny Mayer
Sent: Sat 1/10/2009 10:10 AM
To: Stephane Bortzmeyer
Cc: Adam Langley; [email-masked]
Subject: [dnsext] Re: A custom DNS record for mandatory SSL/TLS

Danny