Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt

From: [email-masked]
Date: Mon, 13 Dec 2010 14:00:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

	Title           : Using Secure DNS to Associate Certificates with Domain Names For TLS
	Author(s)       : P. Hoffman, J. Schlyter
	Filename        : draft-ietf-dane-protocol-00.txt
	Pages           : 9
	Date            : 2010-12-12

TLS and DTLS use certificates for authenticating the server.  Users
want their applications to verify that the certificate provided by
the TLS server is in fact associated with the domain name they
expect.  Instead of trusting a certification authority to have made
this association correctly, the user might instead trust the
authoritative DNS server for the domain name to make that
association.  This document describes how to use secure DNS to
associate the TLS server's certificate with the the intended domain
name.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Dec 2010 23:25:21 +0000

Pretty good.

Questions below. Not expecting fully worked our answers now,
but am expecting them at some point.

- How are self-signed certs handled? Are they type 1/2 or 3/4? I
think picking one and explicitly saying that's how its done would
be best. (I don't care which, I just care that we say exactly how
to use self-signed certs with DANE.)

- How is a hash (or certificate) compared to a trust anchor? 5280
doesn't specify a TA format, though we mostly use self-signed certs.
(Does anything use something else? Does anyone really use rfc 5914
for this?) Might be a bit of a barney to be had about that since
its hard to pick a format that everyone could use, unless everyone
has self-signed certs or you go to the bare public key.

- If an intermediate CA were compromised, then a DNS admin could
obviate the revocation of the relevant CA cert by adding an RR.
Not that likely, and detectable, but maybe worth a security
consideration paragraph since such a case might be fairly
catastrophic as-is, but would be made worse with DANE.

- Practically, we do have an informal partial-order of hash
function strength (md5,sha-1,sha-2). I don't think so, but
would be it worthwhile recommending commensurate-or-better
strength for the hash in this RR compared with the hash used
in the x.509 cert signing alg?

- "If DANE fails then fallback to TLS," seems to open up a
way for an active attacker (say someone who's taken over
my home AP) and who's gotten a faked cert and inserted that
into a TLS handshake to win the game by simply buggering
up the DANE RR bits. Maybe differentiate between DANE
matching failure vs. DNSSEC failures? (Not sure myself
since we start to leak over into policy quickly with
rules in this area.)

- Sort-of editorial: there are too many "if the client
trusts..." type statements. I'm sure that'll get better
over time.

- I'd argue to drop the discussion about exclusion. I
think it only confuses.

- I'd like to understand how or whether I can use this
RR for bare-key protocols. I'm not asking that that all
be worked out now, but only to be convinced that it can
be done later if useful, and to know whether it'd work
based solely on new registry entries for the IANA
registries defined in this document or if I'd need a
new RR or whatever.

- And lastly, the big one: the -00 version is silent on
the "last hop" problem. At minimum I expected a TBD, and
I sure hope that'll be there in a later version. Right?

Other than that last point, this is pretty good.

S.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 14 Dec 2010 02:04:34 +0200

On Mon, Dec 13, 2010 at 11:25:21PM +0000, Stephen Farrell wrote:
> be best.

AFAICT, Type 1 or 2 (match end-entity certificate, which is the only
one).

> catastrophic as-is, but would be made worse with DANE.

That's admins doing stupid things then. The webmaster would for
sure hear about the compromise (required for key rollover!) 
and get the DNS updated.

> up the DANE RR bits.

Only possible by downgrading entiere DNSSEC away (which makes
client expecting signed root to scream really loud).

> registries defined in this document or if I'd need a

This is for TLS, where bare-key would only be possible if there was
a bare-key certificate type. For IPSEC, which has one, one would
follow its certificate type numbers.

-Ilari

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Dec 2010 16:20:29 -0800

>Pretty good.

C'mon, you're usually pricklier than that! :-)

>but am expecting them at some point.

As Warren said earlier, we have a WG secretary, and he'll be opening issues on the WG issue tracker. We can tackle them at any time.

>to use self-signed certs with DANE.)

Yes. That is, if it is a self-signed cert used as an end-entity cert, it is 1/2; if it is used as a CA cert, it is 3/4. That's why we differentiated by semantics, not the format.

>has self-signed certs or you go to the bare public key.

Good point. We should say "...as long as your trust anchors are stored as self-signed certs".

>catastrophic as-is, but would be made worse with DANE.

Good call, yes.

>in the x.509 cert signing alg?

I would want to see a security analysis first. In fact, as long as the hash used in the protecting DNSSEC is "strong enough", I'm not sure that there any attack, is there?

>since we start to leak over into policy quickly with

Urrrgh. Worthy discussion and probably will turn into paragraphs in the doc.

>trusts..." type statements. I'm sure that'll get better

Wording suggestions greatly appreciated.

>- I'd argue to drop the discussion about exclusion. I

It's the term we still hear used, however.

>registries defined in this document or if I'd need a

No, it's for TLS only, which requires a PKIX cert. If there is consensus in the WG to extend it to other protocols, and the extra flexibility is worth it, we can extend it; up to now, no one has shown interest, given that the most obvious bare-key target, SSH, already has its own RRType.

>I sure hope that'll be there in a later version. Right?

Wrong. That work is happening in the DNSEXT WG. Well, it isn't yet, but there is now a draft and a discussion.

>Other than that last point, this is pretty good.

I'm interested in how we can say "must use last-hop technology X" when X doesn't exist. Wording suggestions appreciated.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Dec 2010 20:02:59 -0500

Oh, security considerations, I have some text that may be useful. See
attached.

This is pretty pessimistic and relates to the design I was working on at the
time. But most should carry over.

On Mon, Dec 13, 2010 at 7:20 PM, Paul Hoffman <[email-masked]> wrote:

> As Warren said earlier, we have a WG secretary, and he'll be opening issues
> on the WG issue tracker. We can tackle them at any time.
>
> Yes. That is, if it is a self-signed cert used as an end-entity cert, it is
> 1/2; if it is used as a CA cert, it is 3/4. That's why we differentiated by
> semantics, not the format.
>
> I would want to see a security analysis first. In fact, as long as the hash
> used in the protecting DNSSEC is "strong enough", I'm not sure that there
> any attack, is there?
>
> No, it's for TLS only, which requires a PKIX cert. If there is consensus in
> the WG to extend it to other protocols, and the extra flexibility is worth
> it, we can extend it; up to now, no one has shown interest, given that the
> most obvious bare-key target, SSH, already has its own RRType.
>
> I'm interested in how we can say "must use last-hop technology X" when X
> doesn't exist. Wording suggestions appreciated.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Dec 2010 20:12:05 -0500 (EST)

On Tue, 14 Dec 2010, Ilari Liusvaara wrote:

> sure hear about the compromise (required for key rollover!)

Yes. This is the counter-example of the CAA record. I still think
it is best to limit the interactions of the two authentication
schemes (CAs and dnssec) as much as possible. And while I would
lik the CA not to make statements about dnssec, so should dnssec
not make statement about (intermediate) CA's.

> client expecting signed root to scream really loud).

The question is what to do with the TLSA record if:

1) the record does not validate (servfail)
2) the record validates but the content does not match the
    deployed key/cert
3) the record is there, but we did not get last-mile dnssec

1) includes a "stripping DNSSEC" rogue nameserver, or a nameserver
that is dnssec-unaware. Sometimes this will fail further up the
chain (eg if RRSIG for root data is already stripped) so this
could also influence the clients ability to look up the A record
to begin with. If dnssec works for everything else in the same
zone but not the TLSA record, I'd throw an obvious error, as that
would most likely be an active attack. If it fails higher up in the
chain, perhaps ignore (but not complain) about the TLSA record.

2) is either a sysadmin mistake, or a MITM, and I think an error should
also be thrown notifying the user. Alternatively, one could silently
fail here and let the CA policies do something, but that might be more
dangerous in the case of a rogue/bad CA/cert that is used (eg the * cert
via a MITM attack)

3) here I think we should completely ignore the TLSA record. Even though
it has some value against active attacks only using an IP redirector,
it is just too dangerous that the attacker also modified the TLSA record.

> follow its certificate type numbers.

I'm not sure I follow this. This does not refer to IPSECKEY (RFC4025)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Dec 2010 20:18:40 -0500 (EST)

> I'm interested in how we can say "must use last-hop technology X" when X doesn't exist. Wording suggestions appreciated.

TLSA records must only be trusted if they were obtained from a trusted
source. This could be a localhost resolver answer with the AD bit set, an
inline validating resolver library primed with the proper trust anchors,
or obtained from a remote nameserver to which one has a secured channel
of communication.

[ perhaps they got be stored with TTL in the app too, so that frequent
   network moves would not invalida the data, but possible this is
   already covered in the application usage of DNS in general ]

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Dec 2010 01:19:12 +0000

Hiya,

> C'mon, you're usually pricklier than that! :-)

Seriously - I think this is good, as was your BoF
presentation. (He honestly said, knowing that the
comment might engender a subtle sense of unease
nonetheless:-)

> As Warren said earlier, we have a WG secretary, and he'll be opening issues on the WG issue tracker. We can tackle them at any time.

WG volunteers are wonderful under-appreciated things.

> Yes. That is, if it is a self-signed cert used as an end-entity cert, it is 1/2; if it is used as a CA cert, it is 3/4. That's why we differentiated by semantics, not the format.

Sorry. You've not helped me at least. Why leave self-signed to be
ambiguous between 1/2 and 3/4? There is, IMO, no interesting way
in which a self-signed cert (SSC) is an EE cert and not a CA cert.
That is, an SSC is both. But (even randomly) picking one here is
better than a result where different people make different bad
assumptions as to whether an SSC is an EE or CA cert.

I'll volunteer to honestly toss an honest coin if that helps:-)

> Good point. We should say "...as long as your trust anchors are stored as self-signed certs".

And if they're not? Then there are a class of TLSA values that
just don't work and shouldn't make things worse and that need
to be identified I guess. That is, I think you need to say "if
TA!=SSC then ignore all TLSA values that..."

> I would want to see a security analysis first. In fact, as long as the hash used in the protecting DNSSEC is "strong enough", I'm not sure that there any attack, is there?

I'm ok with no such rule, but think it ought be thrashed a
bit, so I'm happy to just open the discussion and let anyone
else that cares take it up.

> Urrrgh. Worthy discussion and probably will turn into paragraphs in the doc.

I think that'll be needed.

> Wording suggestions greatly appreciated.

I'm sure you'll get 'em. I think its a form better avoided
though wherever possible since each occurrence is a way to
break interop. In order to make a suggestion, maybe think
about phrasing these as "clients SHOULD do <foo> unless
<bar>" if possible. I'm ok waiting to see what you come
up with and commenting on that again later if that helps.

> It's the term we still hear used, however.

Not IMO a good term to use. s/that// would be fine by me.
Can be dealt with later.

> No, it's for TLS only, which requires a PKIX cert. If there is consensus in the WG to extend it to other protocols, and the extra flexibility is worth it, we can extend it; up to now, no one has sh…

So I don't know the details of the SSH RR type. I guess
I ought look. This WG however has IPsec-related milestones
and so the question will need answering ("can the TLSA RR
work for IPsec?"). I happen to think it ought be clear
whether or not the TLSA RR is (D)TLS-only or not before
it gets finished. For me, the answer to that only gets
interesting for protocols that could work with bare
keys. Again, this is one its ok to figure out a bit
later.

> Wrong. That work is happening in the DNSEXT WG. Well, it isn't yet, but there is now a draft and a discussion.

So I guess my eyes passed over the non-existent reference to
that possibly existent draft and got fixated on the DANE
charter. That's liable to keep happening, my eyes reliably
inform me:-)

Seriously though, this is needed if DANE is not to be a
way to weaken TLS. (Which I-D do you mean?)

> I'm interested in how we can say "must use last-hop technology X" when X doesn't exist. Wording suggestions appreciated.

I think the charter text is good here - reference "X" if
it exists or else document it if necessary. Some satisfactory
"X" is clearly, (by my take on the last BoF), necessary
before this WG can meet the "don't make it worse" goal you
yourself posited for the WG, right?

(I could understand if you didn't want to have to write
all the text describing "X" in this I-D, and I guess that's
one for the chairs.)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Dec 2010 01:24:35 +0000

On 14/12/10 01:18, Paul Wouters wrote:
>> I'm interested in how we can say "must use last-hop technology X" when
>> X doesn't exist. Wording suggestions appreciated.
> 
> source. This could be a localhost resolver answer with the AD bit set, 

(As an aside, I think web browsers are a good demonstration that
localhost is no longer considered as good as it once was, in particular,
if some browser vendors are considering re-implementing DNSSEC in the
browser process(es) in order to do DANE well, that would seem to imply
a lack of trust in localhost.)

> an

Which "secured channel of cummunication" and defined where, so that we
get interop? My private magic way of doing this is not IMO good enough
for DANE.

S.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 13 Dec 2010 20:56:43 -0500

> a lack of trust in localhost.)

I think that it is partially a lack of trust in localhost, but more the fact that:
a: there is no simple, clean and interoperable way for the application to get useful dnssec status from the resolver routines.
b: in almost all cases the local resolver is not (yet) dnssec aware.

What will eventually be needed is something like gethostbyname(), that returns the validation state as well as the address, etc.

W

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Dec 2010 20:53:16 -0500 (EST)

> keys. Again, this is one its ok to figure out a bit

I don't think this should be used for IPSEC, as we have IPSECKEY.

One advantage of IPSECKEY for instance, is that you can tell it
to go to a designated third part ipsec gateway. So for example
you could have an IPSECKEY record stating "for www.xelerance.com,
use IPsec with this key/hash using gateway ipsec.xelerance.com".

That way, you can redirect your encrypted traffic to a specifically
designed crypto gateway. And you could enable/disable the crypto
infrastructure by simply removing the DNS IPSECKEY without redesigning
your network.

It also allows "MX style" priorities for load balancing.

These features don't really apply to TLS though, so I don't think it
makes sense incorporating these here. But similarly, it means it
does not make much sense incorporating IPSEC within TLSA either.

Paul

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 14 Dec 2010 09:38:18 +0200

> 	Filename        : draft-ietf-dane-protocol-00.txt

Various unclear things:

- What protects against app managing to load junk keys out of wrong format
  certificate (those junk keys might matematically work an be weak)[1][2]?
- Since hash #0 is identity anyway, is there reason not to merge 1 and 2
  (and also 3 and 4)?
- Do type 3/4 entries match end entity certificate as well, or only other
  certificates?

And then what to do on encountering various kinds nonsense, what should
happen when encountering:

- Record with first two bytes of 01 00?
- Record with first two bytes of 02 02?
- SHA-1 record that is 21 bytes total (truncated record)?
- SHA-1 record that is 23 bytes total (extra stuff after the end)?

[1] draft-hoffman-keys-linkage-from-dns-03 had protection against this.

[2] Granted, it seems pretty unlikely that application can pull anything
out of wrong format certificate. But if there ever will be another 
certificate format using ASN.1, that might not hold anymore...

-Ilari

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Dec 2010 08:39:15 +0100

Thanks for the new document.  The protocol is now hard coded for PKIX,
so that OpenPGP in TLS is not supported.  Is this intentional?  Why was
this changed from earlier documents?  I don't see anything in WG charter
to support this change.

Regards,
/Simon

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 14 Dec 2010 10:01:25 +0100

> a: there is no simple, clean and interoperable way for the application to get useful dnssec status from the resolver routines.

getrrsetbyname(3) is implemented by some operating systems, e.g. OpenBSD.

	jakob

-- 
Jakob Schlyter
Kirei AB - www.kirei.se

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Dec 2010 08:18:22 -0500

I think that is the right decision.

The only reason to support an additional format should be that people intend
to use it and there is an advantage to doing so.

The PGP key format is designed to support Web of Trust. There is no
established Web of Trust for servers and the whole point of this project is
to key off DNSSEC in any case.

If not for the fact that SSL implementations are de facto built on the
assumption of using X.509 certs, there might be an argument to use raw keys.

Using PGP properly in this context is not simply dropping in an additional
format. It would require people to actually build stuff and think about how
it is going to work.

Absent any real world use case for doing so, we should not support PGP or
any other format. If people actually want to use them they can use a
different certificate type identifier, it is what they are there for.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Dec 2010 07:34:07 -0800

>this changed from earlier documents?  I don't see anything in WG charter

1) There are no standards for OpenPGP certificate use in TLS. RFC 5081 is an Experimental RFC. It is inappropriate for a standards-track protocol to try to support non-standard security technologies.

2) There are no good semantics for how to specify the equivalent of a CA in OpenPGP. This would mean that the only useful semantic for DANE would be "a self-signed OpenPGP end-entity certificate". The practical value of that over a self-signed PKIX end-entity certificate is zero.

If those two get fixed in the future, someone can update the protocol to add a new certificate type.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Dec 2010 20:31:56 -0500 (EST)

On Mon, 13 Dec 2010, [email-masked] wrote:

> Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt

My comments below,

Section 2.

This section lists various certificate types. Could we add a type that
just concerns itself with just the pubkey parameters - leaving out as much
of the X.509 as we can. Perhaps the hash would have to cover algorithm,
keysize, pubkey bits. This would strongly point to the certificate just
being a container for the public key, and nothing else. It would also
reduce the "play space" people have for various preimage/hash attacks or
\0 attacks, as the X.509 container has a LOT of scribbling space.

Section 3.1

This section states:

    TLS client policy is deliberately not prescribed by this
    specification.  A client MAY choose to trust a DNSSEC-secured
    certificate association, depending on its local policy.

Perhaps something like:

    A client SHOULD treat DNSSEC-validated certificates as much as possible
    as DV validated certificates.

Section 3.1.1

Some browsers have a CA policy that prevent unvalidated information from
being present in all CA-issued certificates. For DNSSEC validated certs,
the equivalent would be that the certs contain nothing except (roughly)
the key and key usage restrictions. This could also mean leaving blank
the CN, O, OU, etc (as compared to the draft that states "ignore" in
section 3.1.4)

3.1.3.  Use of Local Trust Anchors

See section 3.1.1. This might not match the CA policy for some browsers.

Missing bits.

This might be controversial, but it might be useful to specify some policy
bits. While I'd suggest putting policy in a separate document, it might be
worth having a field here stating there there is additional policy. Later on,
this could be used by DNS servers to send the policy in an new RRTYPE as
additional data. An example policy could be  "https preferred" to avoid
the whole http level Strict-Transport-Security roundtrips. Though this
could probably also be done using a new EDNS option where the client can
request "TLSA and supporting data" along with an A record.

Paul

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 15 Dec 2010 05:01:20 +0200

On Tue, Dec 14, 2010 at 09:38:18AM +0200, Ilari Liusvaara wrote:

>   certificate (those junk keys might matematically work an be weak)?

Ah, apparently the spec limits to certifying PKIX keys. That deals with
this question.

> - SHA-1 record that is 23 bytes total (extra stuff after the end)?

But these other questions still look relevant.

-Ilari

---

From: Steve Schultze <[email-masked]>
Date: Wed, 15 Dec 2010 23:54:15 -0500

"If the application receives zero usable certificate associations, it processes TLS in the normal fashion."

I think that this should read:
"If the application receives zero usable certificate associations, it [MAY process] TLS in the normal fashion."

I originally made this suggestion on draft-hoffman-keys-linkage-from-dns-03 (see the follow-on discussion here for background):
http://www.ietf.org/mail-archive/web/keyassure/current/msg00890.html

And, as I noted during our session in Beijing, the motivation for permitting the client to choose is that if we mandate it one way or the other, we fall into a trap.  If the client MUST process TLS in the normal fashion (aka, using PKIX) then we have provided a solution that is no better than the status quo.  If the client MUST give an "access_denied" error, then nobody will use the standard early on in deployment because the majority of sites will be unreachable.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 16 Dec 2010 09:48:19 +0100

Hi Steve,

It is possible with DNSSEC to distinguish between a failure to lookup
and receiving zero TLSA records DNSSEC secured.  It is also possible to
securely determine if a domain is signed or insecure.

> And, as I noted during our session in Beijing, the motivation for
> permitting the client to choose is that if we mandate it one way or
> the other, we fall into a trap.  If the client MUST process TLS in
> the normal fashion (aka, using PKIX) then we have provided a solution
> that is no better than the status quo.  If the client MUST give an
> "access_denied" error, then nobody will use the standard early on in
> deployment because the majority of sites will be unreachable. 

So, it is possible to say instead:

If there are no TLSA records (this is DNSSEC validated by the lookup) or
the domain is not signed with DNSSEC (this is signed by the parent
domain): process normally (i.e. PKIX).  This provides backwards
compatibility.

Then if the TLSA lookup fails entirely, you have the tradeoff you
mention.  But that means the DNS reply did not arrive, the authority
server fails to answer TLSA lookups or that DNSSEC signatures failed or
something along those lines.

If the TLSA contains malformed entries, (Hi Ilari), the client considers
malformed entries to be a mismatch.  (and then follows normal processing).

Best regards,
   Wouter

---

From: Ben Laurie <[email-masked]>
Date: Thu, 16 Dec 2010 15:07:38 +0000

Looking good. Some comments:

* You don't describe the presentation format

* I don't like "A variable-length set of bytes containing the
certificate or the hash", it makes me wonder how the length is
encoded. Perhaps just "The bytes of the certificate or hash"?

* MD5 should be deprecated.

* "The certificate association is valid if the first certificate in
the certificate bundle can be validly chained to the certificate from
the TLSA data" is theoretically putting a high demand on the client
(where do the certs come from that might chain?). Should say "using
certificates in the bundle"?

* 3.1 confuses me. It seems to say that 3 isn't really there.

* 3.1.1 I don't understand what this means - surely you should process
the cert to ensure it is valid? How can you even use a cert in a
handshake without processing it?

* 3.1.2 should probably be titled "Ignorning Host Names in Self-Signed
Certificates" or be numbered 3.1.1.1.

* 3.1.2 might perhaps usefully refer to virtual hosting, and also
possible relationship with the SNI TLS extension.

* 3.1.4 should probably say "as well as performing TLSA validation".

* 5 - perhaps mention that a rogue domain admin can probably get a
cert issued anyway, so this is not an additional threat.

* "an man-in-the-middle" -> "a man-in-the-middle".

* as someone already mentioned, need to specify what happens when
invalid records are seen.

Cheers,

Ben.

---

From: Steve Schultze <[email-masked]>
Date: Thu, 16 Dec 2010 10:34:40 -0500

> domain): process normally (i.e. PKIX).  This provides backwards

But what if the MITM overrides the genuine DNSSEC-signed record with a record that is not signed with DNSSEC?  Is there some reason why this is not possible?

---

From: Ben Laurie <[email-masked]>
Date: Thu, 16 Dec 2010 15:45:40 +0000

> But what if the MITM overrides the genuine DNSSEC-signed record with a record that is not signed with DNSSEC?  Is there some reason why this is not possible?

Sure it's possible - and then the result is not DNSSEC-signed, and so
should be ignored.

---

From: Steve Schultze <[email-masked]>
Date: Thu, 16 Dec 2010 10:50:39 -0500

> Sure it's possible - and then the result is not DNSSEC-signed, and so

But what does "ignored" mean?  Does it mean the client must give an "access_denied" error?  If so, you fall into the second of my two traps.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 16 Dec 2010 16:03:50 +0000

> 	Filename        : draft-ietf-dane-protocol-00.txt

I think that this

   In order to use one or more TLS certificate associations described in
   this document obtained from the DNS, an application MUST assure that
   the certificates were obtained using DNS protected by DNSSEC.

and this

do not make much sense together.  For instance, if you use TLSA to
limit the circumstances in which certificates validate, it does not
matter if TLSA was received over DNSSEC or not.  This use case is
still interesting because there is currently no way the owner of
example.com can stop browser CAs from issuing certificates for
example.com.

I also don't see how browsers can accept DNSSEC-secured certificate
association in preference of a chain to a root certificate.  It's just
a mess UI-wise.  In my opinion, we should give up and use TLSA to
restrict the set of eligible certificates, and to transparently
upgrade insecure protocols to secure ones (e.g., switch to HTTPS from
HTTP, but display "http://" in the URL bar, an open padlock icon, and
do not transmit secure cookies).  Again, this approach case does not
depend on DNSSEC at all, and it would have a tremendous impact on
passive eavesdropping.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Steve Schultze <[email-masked]>
Date: Thu, 16 Dec 2010 11:42:17 -0500

On Dec 16, 2010, at 11:03 AM, Florian Weimer wrote:
> For instance, if you use TLSA to
> matter if TLSA was received over DNSSEC or not. 

How, other than DNSSEC validation, would you receive a TLSA record that you would trust?

> association in preference of a chain to a root certificate.

You mean a PKIX-provided root certificate?

>  It's just a mess UI-wise.  

I disagree.  If we give the user the option up-front about how to configure their trust, then there is no need to change the rest of the UI at all.  However, the UI *could* be altered to show TLSA-validated sites as "more special" somehow if this was seen as valuable and doable.

> In my opinion, we should give up and use TLSA to
> do not transmit secure cookies).

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Dec 2010 16:42:55 +0000

These traps are real, but the reason they are difficult to address is that
there is too little information provided in one individual response to make
the ideal choice.

One of the reasons that I believe that putting the security processing at a
trusted resolver (and authenticating the client-resolver channel) is
superior is that such resolvers can build up state across multiple lookups
and use that to make better choices.

For example, consider the range of circumstances that can give rise to an
absent signature:-

1) Man in the middle attack
2) Cache poisoning against non-validating resolver
3) Administrator mistake

A trusted and trustworthy resolver can eliminate the first two attack
vectors. If the signature is invalid then a large scale resolver can make a
query from a different source point. Such a resolver is going to be
validating so cache poisoning can be eliminated.

The risk in doing so is that the resolver will react in the same way to
'attacks' and 'mistakes'. To avoid this the resolver can look at the
previous config details and look to see what has changed.

If we have a zone that is unsigned but the key is unchanged, the cause is
rather more likely to be a mistake than an attack. So the best course of
action is probably to tell the client to use the old values and tell the
admin that they seem to have goofed up. Hopefully by some automated means.

Alternatively we might end up defining an additional record that the
resolver could attach to the response to say 'this is an error, but its
probably OK because...'

Of course, if anyone starts to use these mechanisms on an extended scale
there is a risk that it becomes impossible to rely on implicit revocation by
simply delisting the key. And we might have to start thinking about explicit
revocation list processing.

On Thu, Dec 16, 2010 at 3:50 PM, Steve Schultze <[email-masked]> wrote:

> >> But what if the MITM overrides the genuine DNSSEC-signed record with a
> record that is not signed with DNSSEC?  Is there some reason why this is not
> possible?
> >
> But what does "ignored" mean?  Does it mean the client must give an
> "access_denied" error?  If so, you fall into the second of my two traps.

---

From: Steve Schultze <[email-masked]>
Date: Thu, 16 Dec 2010 11:52:11 -0500

On Dec 16, 2010, at 11:42 AM, Phillip Hallam-Baker wrote:
> One of the reasons that I believe that putting the security processing at a trusted resolver (and authenticating the client-resolver channel) is superior is that such resolvers can build up state across multiple lookups and use that to make better choices.

But this assumes:
 - a tremendously more intelligent resolver system than we have today
 - an agreement on the standard for authenticating and encrypting the client-resolver channel
 - very different behavior about resolver configuration (sticky between locations rather than specified by DHCP) for clients that move around

And it introduces a regime in which the ability to securely communicate is dependent on a large (and possibly) external entity.

That doesn't seem great to me.  I think the issues with client management of validation are both easier to solve and more desirable as a security regime where control is in the hands of the edges.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 16 Dec 2010 08:54:31 -0800

AND don't forget, it relies on the premise of a trusted resolver, when we have a large body of evidence that says external resolvers MUST NOT BE TRUSTED.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Dec 2010 12:25:46 -0500 (EST)

> example.com can stop browser CAs from issuing certificates for

That would allow for active attacks though, by spoofing TSLA records.
I think it is fair to say (in this age with a signed root and DLV) that
if you want to avoid the impact of CA's signing certs of your domains,
you deploy DNSSEC with TLSA. Pointing to a non-existent CA using CAA
might be possible, (or perhaps CAA can define some null-CA) but that
seems like a waste of a few lookups to me that just delay the user.

> depend on DNSSEC at all, and it would have a tremendous impact on

Openswan currently does this with Opportunistic Encryption for IPsec, but
again in this age, I think we should move towards DNSSEC proof. Not
only because it is more readilly available, but also because with the
advent of wireless interceptable communiation, the harm of easy active
attacks on last mile wifi is significant over the passive eavesdropping
protection. eg look at firesheep.

I would like to have some EDNS method of signaling what kind of additional
records you are interested in (IPSECKEY, TLSA, SSHFP, etc.) but I don't
think I understand yet if this can be done securely. Eg if these are
stripped away, would I need to do the additional query anyway, or can I
get a proof of non-existence added in the additionals that I can decipher.
I don't know, but I would like some mechanism to bring the latency down
on these extra records which are becoming more and more common and essential
(we hope)

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Dec 2010 12:30:48 -0500

> http://www.ietf.org/mail-archive/web/keyassure/current/msg01086.html

No, Florian's proposal was to opportunistically increase the security of
http URLs (against passive attacks), while my objection was to proposals
that decrease the security of https URLs.

That doesn't mean the idea is useful:

- I don't see the benefit of checking an unsecured TLSA record over
accepting any server certificate.  An active attacker can fake the TLSA
record, and a passive attacker can't fake the server certificate.

- For encryption without server authentication in general, maybe some
secrets will in fact be transmitted encrypted when they wouldn't be
otherwise, but it's not clear what assurance we could offer the user,
especially as long as non-upgraded http://example.com is in the same
security origin as upgraded http://example.com .

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Dec 2010 12:31:00 -0500 (EST)

On Thu, 16 Dec 2010, Phillip Hallam-Baker wrote:

> If we have a zone that is unsigned but the key is unchanged, the cause is rather more likely to be a mistake than an attack.

Is it? That's exactly how an attacked DNSSEC stripped zone would look like. You can't have protocol guessing at this point.
The admin broke it, and it is broken until they fix it.

> So the
> best course of action is probably to tell the client to use the old values and tell the admin that they seem to have goofed up.
> Hopefully by some automated means.

That is the most dangerous action to take, and would seriously devalue the trust in DNSSEC.

I'm not a browser vendor, or a UI expert, but I think the course of action would be for this to be a fatal error,
and most likely you don't want the user to be able to click "i dont care, continue"

> Alternatively we might end up defining an additional record that the resolver could attach to the response to say 'this is an error,
> but its probably OK because...'

There can never be an unsigned record that says "its ok to ignore DNSSEC". It's the same as me telling your
browser "Its okay to add my CA to your trust pool" without any trust.

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Dec 2010 12:32:52 -0500

> protection. eg look at firesheep.

That's not the example you want.  Firesheep does passive eavesdropping.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Dec 2010 17:32:55 +0000

It exists today, quite a large number of people are using it, Comodo, Google
and OpenDNS are already offering services that will obviously evolve into
this model over time.

It is rather closer to the original model of DNS than the change necessary
to adopt an end to end model.

Having had actual experience of deploying end-to-end 'solutions', I am
rather less impressed by the concept than I was 20 years ago. In my
experience they tend to turn out to be impossible to deploy and difficult to
use.

If you want to solve this corner case you need more information than you can
reasonably expect to be available at the end point.

We already have a spec for securing the connection. It is currently
proprietary but we are proposing the successor as an open, non-proprietary
protocol.

On Thu, Dec 16, 2010 at 4:52 PM, Steve Schultze <[email-masked]> wrote:

> > One of the reasons that I believe that putting the security processing at
> a trusted resolver (and authenticating the client-resolver channel) is
>  - very different behavior about resolver configuration (sticky between
> locations rather than specified by DHCP) for clients that move around
>
> And it introduces a regime in which the ability to securely communicate is
> dependent on a large (and possibly) external entity.
>
> That doesn't seem great to me.  I think the issues with client management
> of validation are both easier to solve and more desirable as a security
> regime where control is in the hands of the edges.

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Dec 2010 12:38:23 -0500

On Thu, 2010-12-16 at 10:34 -0500, Steve Schultze wrote:
> record that is not signed with DNSSEC?  Is there some reason why this
> is not possible?

We have been through this already...

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

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Dec 2010 17:46:46 +0000

On Thu, Dec 16, 2010 at 5:31 PM, Paul Wouters <[email-masked]> wrote:

>> rather more likely to be a mistake than an attack.
>>
>
> Is it? That's exactly how an attacked DNSSEC stripped zone would look like.
> You can't have protocol guessing at this point.

If the IAB can't keep their zone signed, what hope for the rest?

Real world users tend to be more interested in functionality than some
abstract notion of what you imagine security to be.

Cryptography is the easy part. Working out how to make use of the
information is hard.

In my scheme, I block the Russian Business Network and other criminal
controlled sites. That is what 98% of Internet users consider to meet their
real security needs.

---

From: Stephen Schultze <[email-masked]>
Date: Thu, 16 Dec 2010 13:12:26 -0500

On Dec 16, 2010, at 12:38 PM, Matt McCutchen wrote:
>>>> "If the application receives zero usable certificate  
>>>> associations, it
>>>> processes TLS in the normal fashion."
>>>

Yes, but evidently we didn't come to a conclusion.  Wouter's proposal  
(which I take to be "MUST process TLS in the normal fashion") creates  
the sort of downgrade attack I was describing here and in that  
thread.  The current draft likewise does so:

"If the application receives zero usable certificate associations, it  
processes TLS in the normal fashion."

Or am I missing something?

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Dec 2010 13:14:51 -0500

On Thu, 2010-12-16 at 17:46 +0000, Phillip Hallam-Baker wrote:
>                 If we have a zone that is unsigned but the key is
>                 unchanged, the cause is rather more likely to be a
>                 mistake than an attack.
>         
>         
>         Is it? That's exactly how an attacked DNSSEC stripped zone
>         would look like. You can't have protocol guessing at this
>         point.

Did the IAB have trouble keeping their zone signed?  I wasn't aware that
they did.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Dec 2010 13:20:51 -0500

> Or am I missing something?

AIUI, that line is within the case in which the DNSSEC query has
succeeded.  That could be clarified by changing the paragraph to:

---
An application that performs a successful DNSSEC query for TLS
certificate associations using the method described in this document
obtains zero or more usable certificate associations.  If the
application receives zero usable certificate associations, it processes
TLS in the normal fashion.
---

Or adopting my text from:

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

-- 
Matt

---

From: Stephen Schultze <[email-masked]>
Date: Thu, 16 Dec 2010 13:24:14 -0500

On Dec 16, 2010, at 11:42 AM, Phillip Hallam-Baker wrote:
> One of the reasons that I believe that putting the security  
> processing at a trusted resolver (and authenticating the client- 
> resolver channel) is superior is that such resolvers can build up  
> state across multiple lookups and use that to make better choices.

On Thu, Dec 16, 2010 at 4:52 PM, Steve Schultze <[email-masked]>  
wrote:
>  - very different behavior about resolver configuration (sticky  
> between locations rather than specified by DHCP) for clients that  
> move around
>
> And it introduces a regime in which the ability to securely  
> communicate is dependent on a large (and possibly) external entity.
>
> That doesn't seem great to me.  I think the issues with client  
> management of validation are both easier to solve and more desirable  
> as a security regime where control is in the hands of the edges.

On Dec 16, 2010, at 12:32 PM, Phillip Hallam-Baker wrote:
> It exists today, quite a large number of people are using it,  
> Comodo, Google and OpenDNS are already offering services that will  
> obviously evolve into this model over time.
>
> It is rather closer to the original model of DNS than the change  
> necessary to adopt an end to end model.
>
> Having had actual experience of deploying end-to-end 'solutions', I  
> am rather less impressed by the concept than I was 20 years ago. In  
> my experience they tend to turn out to be impossible to deploy and  
> difficult to use.
>
> If you want to solve this corner case you need more information than  
> you can reasonably expect to be available at the end point.
>
> proprietary but we are proposing the successor as an open, non- 
> proprietary protocol.

Feel free to publish that standard, and it can potentially be  
compatible with the DANE spec's requirement that answers be DNSSEC- 
validated.  It will always have the disadvantage of requiring end  
users to delegate security responsibility to a third party.   
Furthermore, for it to have the advantages you described in the case  
of non-DNSSEC-validated responses, it will also have to have some  
squishy heuristics around when to trust past/alternative results and  
the like.  Building such indeterminacy into our spec be default  
doesn't seem like a path to a strong security protocol, but offering  
it as an option to users seems reasonable.

---

From: Stephen Schultze <[email-masked]>
Date: Thu, 16 Dec 2010 13:32:35 -0500

On Dec 16, 2010, at 1:20 PM, Matt McCutchen wrote:
> succeeded.

That's not how I read it.  All that section says is "In order to use  
one or more TLS certificate associations described in this document  
obtained from the DNS, an application MUST assure that the  
certificates were obtained using DNS protected by DNSSEC."  In the  
case of no DNSSEC validation, and fallback to standard PKIX, the  
client would not be "us[ing] one or more TLS certificate  
associations... obtained from the DNS."  It would be using the  
contents of the cert provided by the TLS handshake.

> That could be clarified by changing the paragraph to:
>
> ---

But what if the client does not want to fall back on PKIX TLS even if  
the site operator has not yet deployed DANE?  Should that not be an  
option for the client?   This would argue for a MAY, rather than the  
implied MUST above.

> http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html

Yes, I think that this part of your text solves the problem I am  
raising:
"Otherwise, if any query gives an "insecure" or "indeterminate"  
result, KIDNS cannot be used with this TLS server, and the client MAY  
use an alternative certificate validation method."

---

From: Martin Rex <[email-masked]>
Date: Thu, 16 Dec 2010 19:45:56 +0100 (MET)

Paul Wouters wrote:
> > So the best course of action is probably to tell the client to use
> > the old values and tell the admin that they seem to have goofed up.

You may want to distinguish two types of "old values":

 - Caching RRs beyond TTL expiration should not be a problem and is IMHO
   permitted by the spec as a fallback.

 - Using a signed RR beyond the Signature Expiration Date is undesirable,
   though.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Dec 2010 18:50:07 +0000

On Thu, Dec 16, 2010 at 6:24 PM, Stephen Schultze <[email-masked]> wrote:

>
> Feel free to publish that standard, and it can potentially be compatible
> with the DANE spec's requirement that answers be DNSSEC-validated.  It will
> always have the disadvantage of requiring end users to delegate security
> responsibility to a third party.  Furthermore, for it to have the advantages
> you described in the case of non-DNSSEC-validated responses, it will also
> have to have some squishy heuristics around when to trust past/alternative
> results and the like.  Building such indeterminacy into our spec be default
> doesn't seem like a path to a strong security protocol, but offering it as
> an option to users seems reasonable.

Since the purpose of the standard would be to enable that exact model, it
can hardly be seen as a 'disadvantage'.

In the long term we can expect deployment of DNSSEC to stabilize to the
point that it may become practical to employ the strong end-to-end approach
on certain clients. But any scheme that relies on that approach is going to
prove brittle in deployment.

There is a very important difference between security features and security.
The academic approach to cryptography tends to over-emphasize security
features and concentrate on a small, unrepresentative set of attacks, it
ignores the complexity that makes real security hard.

Attacks change over time. A security measure that is entirely deterministic
has no capability to adapt to respond to new attacks.

Having some degree of play in the system can be a very good thing, provided
that is that the control over the degree of play is properly accountable.

---

From: Stephen Schultze <[email-masked]>
Date: Thu, 16 Dec 2010 13:56:49 -0500

On Dec 16, 2010, at 1:50 PM, Phillip Hallam-Baker wrote:
> Since the purpose of the standard would be to enable that exact  
> model, it can hardly be seen as a 'disadvantage'.
>
> In the long term we can expect deployment of DNSSEC to stabilize to  
> the point that it may become practical to employ the strong end-to- 
> end approach on certain clients. But any scheme that relies on that  
> approach is going to prove brittle in deployment.
>
> There is a very important difference between security features and  
> security. The academic approach to cryptography tends to over- 
> emphasize security features and concentrate on a small,  
> unrepresentative set of attacks, it ignores the complexity that  
> makes real security hard.
>
>
> Attacks change over time. A security measure that is entirely  
> deterministic has no capability to adapt to respond to new attacks.
>
> Having some degree of play in the system can be a very good thing,  
> provided that is that the control over the degree of play is  
> properly accountable.

We are going to have to agree to disagree.  I think that the past 10  
years has demonstrated a constant degradation of the "trusted third  
party" model in the context of PKIX (as a cryptographic, operational,  
and governance matter).  One of DANE's comparative advantages is that  
it makes it possible to push control to the edges.  Re-introducing  
centralized dependencies and ambiguities is a disadvantage in my  
view.  It is also mismatched with the thrust of all of this groups  
efforts so far, but if I'm wrong I'm sure someone other than you will  
pipe up in support.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 16 Dec 2010 19:58:45 +0100

> How, other than DNSSEC validation, would you receive a TLSA record

DNS+TSIG?

/Simon

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Dec 2010 14:01:00 -0500

> contents of the cert provided by the TLS handshake.

You are right.  That has to be a mistake.

> option for the client?   This would argue for a MAY, rather than the  

Right, I think the fallback method should be unspecified.  It's useful
to be able to speak of DANE-compliant clients that fall back to PKIX,
something else, or nothing at all.  But this is a separate issue, so I
didn't address it in giving a small fix for the downgrade issue.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Dec 2010 14:15:52 -0500

On Thu, 2010-12-16 at 13:56 -0500, Stephen Schultze wrote:
> I think that the past 10  
> and governance matter).

Let no one miss that DANE as it is to be commonly practiced still
depends on third parties: ICANN/Verisign and whoever else is on the path
to one's zone.  Hopefully they will be less unruly than the public CAs,
but people who are serious about not trusting third parties will still
need something else.

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Dec 2010 14:21:07 -0500 (EST)

>> How, other than DNSSEC validation, would you receive a TLSA record

That would be "DNS+TSIG from a trusted soure". If you don't use DNSSEC
and the server you have a TSIG-like trust relationship with is not the
authoratative server, then you still don't know if they got it securely
(and you're not validating it).

One more reason of course for end to end DNSSEC.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Dec 2010 14:23:30 -0500 (EST)

> but people who are serious about not trusting third parties will still

The big difference is that if you are mobile, attackers will have to falsify
the public's view of DNS(SEC), so this becomes very obvious. Contrary to using
one of many CA's to sign something bad, knowing your laptop is preloading with
trust to that CA (one of 1500+, so you can't realisticly audit your laptop for
CA trust)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Dec 2010 14:28:41 -0500 (EST)

>   permitted by the spec as a fallback.

That would be dangerous - you might miss the purposeful removal of some
TLSA (eg after the private key of the webserver got compromised)

I would say that TTL and RRSIG expiry time fall within what the DNSSEC
authority (signer) security stated about the TLSA record. A TLSA enabled
client MUST adhere to those obtained values.

The "leap of faith" with ssh was based on doing this because there was no
concept of expiry. But if you now set "VerifyHostKeyDNS yes" for ssh, then
if the SSHFP record is not a match, and you have the old key in your
knwon hosts file, it WILL warn you before using that key - as it should!

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Dec 2010 14:45:02 -0500

On Thu, 2010-12-16 at 14:23 -0500, Paul Wouters wrote:
> the public's view of DNS(SEC), so this becomes very obvious.

Really?  I remember someone describing how a rogue registrar could
target a false answer to one user, but I haven't been able to find the
message now.

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Dec 2010 14:53:58 -0500 (EST)

> target a false answer to one user, but I haven't been able to find the

I am not sure how they would distinguish me from someone else's DNS query?

Also, I would recommend to preload your own zone's trust anchor in your local
resolver, so that outages and possibly subversion attempts will at least fail
for all of the resoures under your own (zone) control.

Paul
(yes my resolvers have xelerance.com/xelerance.net DNSKEY's preloaded)

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Dec 2010 14:59:59 -0500

On Thu, 2010-12-16 at 18:50 +0000, Phillip Hallam-Baker wrote:
>         compatible with the DANE spec's requirement that answers be
>         DNSSEC-validated.  It will always have the disadvantage of
>         requiring end users to delegate security responsibility to a
>         third party.  Furthermore, for it to have the advantages you
>         described in the case of non-DNSSEC-validated responses, it
>         will also have to have some squishy heuristics around when to
>         trust past/alternative results and the like.  Building such
>         indeterminacy into our spec be default doesn't seem like a
>         path to a strong security protocol, but offering it as an
>         option to users seems reasonable. 
> 
> 
> Since the purpose of the standard would be to enable that exact model,
> it can hardly be seen as a 'disadvantage'.

I assume you're referring to the delegation of security responsibility
to the registrars on the path?  Yes, the purpose of the standard is to
enable delegation -- to the parties authoritative for the resolution of
the name, not providers of DNSSEC resolution services.

> the point that it may become practical to employ the strong end-to-end
> approach on certain clients. But any scheme that relies on that

What is unstable now?  If today I sign my zone and my friend sets up his
hypothetical DANE client to use some working DNSSEC server and connects
to my TLS server, what do you envision going wrong?

> provided that is that the control over the degree of play is properly
> accountable.

TLS seeks to achieve complete integrity modulo the security of the
endpoints and cryptographic algorithms and leaves availability to the
network operators.  It seems that a server authentication method that
seeks to achieve complete integrity (with respect to the registrars) and
leaves availability to the DNS operators would be a good complement.

Assuming a focus on integrity, I don't see how your specific proposal to
accept old keys in some cases when the DNSSEC signature has disappeared
would help.  More generally, one can imagine that a resolution service
might be able to respond to certain classes of new attacks on behalf of
its users.

In any case, I agree with Stephen that such things don't belong in the
DANE spec.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Dec 2010 15:44:05 -0500

> the name, not providers of DNSSEC resolution services.

Phillip has pointed out to me that I misunderstood, and the "standard"
there is the one for external resolvers, not DANE.  Never mind my
remark.

I'll agree with Stephen that exposure to a third party, compared to no
exposure, is a disadvantage, but of course that has to be put in
context.  Some clients may find that an external resolver meets their
needs well.

-- 
Matt

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 16 Dec 2010 22:16:17 +0100

Hi Stephen,

>>> record that is not signed with DNSSEC?  Is there some reason why this

You can detect this, the result is DNSSEC bogus: access denied.

> the sort of downgrade attack I was describing here and in that thread. 
> The current draft likewise does so:

No, I mean something different, see below.

> Or am I missing something?

Distinguish zero TLSA objects (DNSSEC signed): no TLSA configured, so do
the 'usual' (no TLS or normal TLS).

And some TLSA objects.  Malformed ones are not usable, mismatches are
not usable.  If none are usable, since TLSA is configured, no downgrade
with TLS processing: access denied.

If usable TLSA objects: you have a match, yay.  Do what the draft says.

If domain not DNSSEC signed (insecure): normal TLS (or no TLS).

If TLSA query fails (no reply from network, all traffic disappears):
access denied. (This is the part where I think your trap still applies,
but it is much smaller than before: not many DNSSEC-signed domains will
fail to resolve a TLSA query; they usually upgrade software and thus
also support the unknown-RR-types RFC).

Would that come out of the trap?

Best regards,
   Wouter

---

From: Martin Rex <[email-masked]>
Date: Thu, 16 Dec 2010 22:17:32 +0100 (MET)

> TLSA (eg after the private key of the webserver got compromised)

No, that would not be dangerous at all.
TTL is a suggested, soft expiration for the purpose of cache management.

There is no revocation mechanism in DNS, and the time of expiration
for a signed record is explicitly given in the Signature expiration.

But even when the time advances beyond signature expiration,
that doesn't mean that a cached record, obtained and added to the
cache while it was still valid (both signature and TTL) will
automatically become malicious.

> client MUST adhere to those obtained values.

That is not how DNS works.  The TTL relevant for caching is not
even covered by the DNSSEC signature.

> knwon hosts file, it WILL warn you before using that key - as it should!

That "VerifyHostKeyDNS" looks like a security vulnerability to me.

Keys do not expire.  If anything, they get compromised (or if they're
extremely weak, they might get brute-forced).

-Martin

---

From: James Cloos <[email-masked]>
Date: Thu, 16 Dec 2010 16:16:41 -0500

>>>>> "SS" == Steve Schultze <[email-masked]> writes:

>> If there are no TLSA records (this is DNSSEC validated by the lookup)
>> or the domain is not signed with DNSSEC (this is signed by the parent

SS> But what if the MITM overrides the genuine DNSSEC-signed record with
SS> a record that is not signed with DNSSEC?  Is there some reason why
SS> this is not possible?

The bottom line is that the policy in that case needs to be user-specific.

A flag day between the current regime and the use of the dns root key as
the universal trust anchor will never fly.  The only thing which will is
to allow some users to upgrade to the new mechanism while the rest stick
for a while with the current.

For that to work, a lack of dns trust has to fall back to the collection
of root CAs model.

DAME does need to document the risk that a MITM can degrade the dns to
unsecured and trick a user into using the old model.

In theory, it would help were apps to keep track of secure remotes which
were trusted because of the root dns key, and complain whenever that trust
path disappears.  Or, when it comes to that, when it changes in any way.

But experience shows that most people tend to ignore that kind of warning.

There is little DANE can do beyond documenting the risks.

Personally, I'd prefer that UIs always let me know why something which
appears to be secure is trusted.  And I'd like to track any transition
from one global trust policy to another.  In the case of a GUI browser,
a different background colour for the URL bar and a slightly different
padlock appearance would be ideal.  (At least when the trust path is
homogeneous. ☺)

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Dec 2010 16:25:36 -0500 (EST)

On Thu, 16 Dec 2010, W.C.A. Wijngaards wrote:

> fail to resolve a TLSA query;

In fact, either the entire zone broke, in which case you couldn't resolve
the website there to begin with, and are not attempting a TLSA record, or
the TLSA record is specifically filtered/modified, in which case it is an
active attack you want to protect against.

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Dec 2010 16:31:19 -0500

> For that to work, a lack of dns trust has to fall back to the collection

And that works fine when the client gets a "secure" DNSSEC result with
zero TLSA records or an "insecure" result.  On the other hand, a "bogus"
result means the system is misconfigured or under attack.  I don't see
why there is a demand that the system continue to function in such an
event.

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Dec 2010 16:32:05 -0500 (EST)

> even covered by the DNSSEC signature.

I was wrong. Thanks for pointing it out....

> That "VerifyHostKeyDNS" looks like a security vulnerability to me.

It adds information to your prompt. I'm not sure how that could be a
security vulnerability. Instead of "yes" you can also configure "ask".

Paul

---

From: Stephen Schultze <[email-masked]>
Date: Thu, 16 Dec 2010 16:43:21 -0500

> You can detect this, the result is DNSSEC bogus: access denied.

Upon re-reading RFC 4033, you seem to be correct.  Am I correct in  
understanding that once you put a DS record in your parent zone, any  
non-signed response from your own zone gives a DNSSEC bogus status?

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Dec 2010 16:46:06 -0500

> non-signed response from your own zone gives a DNSSEC bogus status?

Yep.  Isn't it great?

-- 
Matt

---

From: Stephen Schultze <[email-masked]>
Date: Thu, 16 Dec 2010 16:54:14 -0500

>> non-signed response from your own zone gives a DNSSEC bogus status?

It is, and I now understand and wholeheartedly support the entirety of  
your suggested text as a complete solution to my concerns.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Dec 2010 09:19:00 +1100

> target a false answer to one user, but I haven't been able to find the

A rogue registry that controls all of the DNS servers for the zone
could do this.  A registrar could not as they just add data to the
zone without control of to whom it is being sent.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 16 Dec 2010 17:23:54 -0500

> zone without control of to whom it is being sent.

I guess I meant the registry.  Pardon my sloppy terminology.  The
registrar is on the path and could substitute a false DS but has no way
to target individual clients.

-- 
Matt

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Dec 2010 09:47:31 +1100

In message <[email-masked]>, "W.C.A. Wijngaards" writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Stephen,
> 
 
Additionally the validators also usually support unknown types.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Dec 2010 09:51:43 +1100

> even covered by the DNSSEC signature.

Actually it is.  The SIG record contains a upper bound and that value is
part of what is signed.

---

From: Martin Rex <[email-masked]>
Date: Fri, 17 Dec 2010 00:33:40 +0100 (MET)

> Actually it is.  The SIG record contains a upper bound and that value is

I am definitely _no_ DNSSEC expert, but 
the way I interpret the architecture described here:

  http://tools.ietf.org/html/rfc4034#section-3.1
  http://tools.ietf.org/html/rfc4035#section-5.3.2

an attacker should be able to replay a DNSSEC response with an
attacker-chosen TTL (0 < TTL <= Orig-TTL) arbitrarily within the
RRSET lifetime specified through Signature Expiration and Inception Fields

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Dec 2010 10:58:11 +1100

> RRSET lifetime specified through Signature Expiration and Inception Fields

Correct.  That doesn't however mean the TTL is not covered.  It is.

Mark

---

From: Martin Rex <[email-masked]>
Date: Fri, 17 Dec 2010 01:18:45 +0100 (MET)

Mark Andrews wrote:
> Martin Rex wrote:

Orig-TTL is covered by the RRSET signature, but Orig-TTL is
irrelevant to the caching.  The TTL provided by nameservers
and relevant to the caching by other name server and clients
is _not_ protected at all.  Therefore it is futile to think
of TTL as a security feature.

  A sensibly bounded OrigTTL is security-relevant.
  The enforcement of  TTL < OrigTTL is security-relevant

  The acutal value TTL or TTL=0 is _not_ security relevant
  and is _not_ covered by the DNSSEC protection

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Fri, 17 Dec 2010 12:57:55 -0500 (EST)

>> Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt

I actually had one more comment. I realised that the TLSA record can protect
against Moxy's sslstrip (http://www.thoughtcrime.org/software/sslstrip/)

Could we add something like:

 	If a client detects a validated TLSA record, it MUST only use https (not http)
 	to connect to the target site to prevent SSL stripping attacks.

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 17 Dec 2010 13:12:39 -0500

>  	to connect to the target site to prevent SSL stripping attacks.

No.  The sole purpose of TLSA is to determine which keys/certificates
are valid for a TLS connection.  What you describe is Strict Transport
Security, which is being pursued separately.  It will probably have its
own record in DNSSEC.

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

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 17 Dec 2010 10:27:41 -0800

>	to connect to the target site to prevent SSL stripping attacks.

Probably not. That is, if the user is not going to TLS (because the server doesn't do TLS or a MITM has done a downgrade to non-TLS), they should not be looking for TLSA records.

The attack you are concerned with is being dealt with in the WEBSEC WG (for the HTTP case) and hopefully by draft-hoffman-server-has-tls (depending on how the WEBSEC WG moves forwards).

--Paul Hoffman, Director
--VPN Consortium

---

From: Adam Langley <[email-masked]>
Date: Fri, 17 Dec 2010 13:38:32 -0500

On Fri, Dec 17, 2010 at 1:27 PM, Paul Hoffman <[email-masked]> wrote:
> The attack you are concerned with is being dealt with in the WEBSEC WG (for the HTTP case)

Indeed. HSTS appears to be the emerging standard around this for
browsers: http://dev.chromium.org/sts

AGL

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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 17 Dec 2010 14:07:33 -0500 (EST)

> The attack you are concerned with is being dealt with in the WEBSEC WG (for the HTTP case) and hopefully by draft-hoffman-server-has-tls (depending on how the WEBSEC WG moves forwards).

Hmm, so draft-hoffman-server-has-tls-01 defines a HASTLS record. Execsum:

 	www.example.com IN HASTLS (25 25 0 443)

But we have no method defined anyway to get all this information at once. So now this becomes two full roundtrip DNS queries
to get enough information about the pubkey used on a website. Is there any work being done on optimising this with an EDNS
option?

Is there any reason why the TLSA and HASTLS records could not be merged into one RRTYPE to save a roundtrip?
Why aren't we doing something like:

 	www.example.com IN HASTLS (25 25 KeyType FingerPrint 0 443 KeyType FingerPrint)

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 17 Dec 2010 11:14:09 -0800

>browsers: http://dev.chromium.org/sts

Hopefully so, but note that HSTS is far from settled technically. It will probably be the next big discussion once the WEBSEC WG gets a bit more active.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Fri, 17 Dec 2010 14:17:40 -0500 (EST)

> Hopefully so, but note that HSTS is far from settled technically. It will probably be the next big discussion once the WEBSEC WG gets a bit more active.

Also, this does not address the issue where we can shut off port 80 completely. We need a non-http/https
based piece of information for that. HASTLS or TLSA would do - a combination record might do better!

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 17 Dec 2010 14:19:11 -0500 (EST)

> Security, which is being pursued separately.  It will probably have its

A quick read, it looked more like an HTTP header then a DNS record?

So that would be THREE records to lookup before we know how to properly and safely
contact a website with a pubkey placed in dns......

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 17 Dec 2010 11:32:26 -0800

At 2:07 PM -0500 12/17/10, Paul Wouters wrote:
>to get enough information about the pubkey used on a website.

Not at all. If you are about to do TLS and only TLS, then you don't need to query for HASTLS: it is only if you want to do TLS but cannot get there that you need to do HASTLS.

> Is there any work being done on optimising this with an EDNS
>option?

It's a thought, but one that has not garnered much interest in the past.

>	www.example.com IN HASTLS (25 25 KeyType FingerPrint 0 443 KeyType FingerPrint)

Because the "this host serves TLS and non-TLS" and "when we serve TLS, this is the key we will use" semantics are orthogonal. Having orthogonal semantics in the same record often leads to implementations that do not interoperate.

--Paul Hoffman, Director
--VPN Consortium

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 17 Dec 2010 14:39:17 -0500

> It's a thought, but one that has not garnered much interest in the past.

Too bad.  This issue is going to come up every time we want browsers to
get some new piece of information from DNSSEC.  E.g., it would be nice
to move the public suffix list (http://publicsuffix.org) that is
currently shipped with browsers into DNSSEC.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 17 Dec 2010 11:41:26 -0800

A quick followup: I do not mean to sound that it is bad or not possible to do what you are asking, just that it had been discussed a bit before we were a WG.

Jakob and I have an agreement with Warren and Ondrej that we are document editors, not authors. We take direction from the chairs about what major changes should be made. We will do editorial changes and non-controversial "please add a sentence explaining this better" without making the chairs tell us, but technical changes come from the WG through the consensus process.

You might find Jakob or I arguing one way or another on technical suggestions in the WG. We are doing so as WG members, not document authors.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Fri, 17 Dec 2010 14:42:23 -0500 (EST)

> Not at all. If you are about to do TLS and only TLS, then you don't need to query for HASTLS: it is only if you want to do TLS but cannot get there that you need to do HASTLS.

But how do you start? Attempting 443 before going to 80? That would also be a roundtrip to detect.
And then after you got a connect on port 443, you need to do the lookup for TLSA. We could still
safe a round trip here. Ideally, one DNS lookup and get the TLS information (hastls+tlsa) and
one tcp connection to the right port. And in absense of TLSA/HASTLS, go to port 80 (and perhaps
get an HTTP STS header to go to port 443 and use PCIX CA chains)

> It's a thought, but one that has not garnered much interest in the past.

I'd be interested on working on that, ideally with more then just these specific options.
But I have not figured out how to be able to trust the lack of additional records with
a validatable response those other records were not there.

> Because the "this host serves TLS and non-TLS" and "when we serve TLS, this is the key we will use" semantics are orthogonal. Having orthogonal semantics in the same record often leads to implement…

Less prone to interop issues then giving them TLSA/HASTLS records in the additional section of
an A record lookup?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 17 Dec 2010 11:44:07 -0800

>based piece of information for that. HASTLS or TLSA would do - a combination record might do better!

Again, that's what will be being discussed in WEBSEC. Note that that WG *only* cares about HTTP (80 and 443), whereas TLSA is for all TLS-using applications. If that turns out to be a problem, we may need to move this to the Apps Area mailing list.

--Paul Hoffman, Director
--VPN Consortium

---

From: Brian Smith <[email-masked]>
Date: Fri, 17 Dec 2010 11:52:24 -0800 (PST)

Paul Wouters wrote:
> Paul Hoffman wrote:
> >> But we have no method defined anyway to get all this information at
> >> once. So now this becomes two full roundtrip DNS queries
> > Not at all. If you are about to do TLS and only TLS, then you don't
> > need to query for HASTLS: it is only if you want to do TLS but
> > cannot get there that you need to do HASTLS.
> 
> But how do you start? Attempting 443 before going to 80? That would
> also be a roundtrip to detect. And then after you got a connect on
> port 443, you need to do the lookup for TLSA. We could still safe
> a round trip here. Ideally, one DNS lookup and get the TLS
> information (hastls+tlsa) and one tcp connection to the right port.
> And in absense of TLSA/HASTLS, go to port 80 (and perhaps get an
> HTTP STS header to go to port 443 and use PCIX CA chains)

Yes, this is exactly the right case to optimize for. DNS should
immediately give us enough information to know whether to try HTTPS
on port 443 or HTTP on port 80. And, in the HTTPS-is-available case,
we should the authenticated (ephemeral) public key material before
making the TCP connection so that we can use something like TLS Snap
Start for servers we've never even contacted.

Cheers,
Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 17 Dec 2010 19:53:18 +0000

I will just point out that you have come essentially to the scheme I
proposed six months back at the start of all this.

It makes perfect sense to combine 'must use TLS' with 'must use this key'.

However to make that work you need to have protocol level granularity. And
then you hit the problem that protocol prefixes only work for canonical
names.

Hence, I think that you will find that to meet the full set of use cases you
would want to support, you need to address discovery as well.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 17 Dec 2010 15:25:58 -0500 (EST)

On Fri, 17 Dec 2010, Phillip Hallam-Baker wrote:

> I will just point out that you have come essentially to the scheme I proposed six months back at the start of all this.
> However to make that work you need to have protocol level granularity. And then you hit the problem that protocol prefixes only work
> for canonical names.

Can you explain this to me in some concrete terms? I don't understand "protocol level granularity" nor "protocol prefixes"?

I think with "protocol level granularity" you mean specifying services/ports?
I'm not sure what "protocol prefix" would be?

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 17 Dec 2010 15:41:02 -0500

> Start for servers we've never even contacted.

For Snap Start to work, the ServerSnapStart extension will need to be
published in DNS too.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 17 Dec 2010 20:41:51 +0000

If you are going to say 'must use TLS' you are going to have to specify the
protocol.

HTTP is not the only protocol that uses TLS, it is used on SMTP, POP3, IMAP,
etc.

So any useful security policy mechanism is going to have to allow for
protocol specific statements to be made. The natural mechanism to use for
this is SRV style prefixes.

_http._tcp.example.com POLICY "Always use TLS and use key X"
_pop3._tcp.example.com POLICY "Hey use TLS if you like man, the key is Y"

Protocol level granularity is essential, but if you combine with SRV
processing, you can address protocol-host level granularity.

This one actually makes automating management very clean. A host offering a
service can specify its keys and security parameters at the same time.

On Fri, Dec 17, 2010 at 8:25 PM, Paul Wouters <[email-masked]> wrote:

>> then you hit the problem that protocol prefixes only work
>> for canonical names.
>>
>
> Can you explain this to me in some concrete terms? I don't understand
> "protocol level granularity" nor "protocol prefixes"?
>

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 17 Dec 2010 15:44:54 -0500

> a validatable response those other records were not there.

It should be easy enough: in any case in which the server would have
returned a record had it existed, return the NSEC record instead.

I guess there are two approaches: the server could add records it thinks
the client wants, or the client could ask for all records it wants.  For
the second approach, there is an old draft for queries with multiple
questions:

http://tools.ietf.org/html/draft-ietf-dnsext-edns1-03#section-4

Unfortunately, existing servers seem to reject queries with QDCOUNT > 1
with a format error.  So to minimize the number of round trips, we would
need a different mechanism with the property that servers that don't
support it will still give one answer.

-- 
Matt

---

From: Adam Langley <[email-masked]>
Date: Fri, 17 Dec 2010 16:19:57 -0500

> For Snap Start to work, the ServerSnapStart extension will need to be

Snap Start is still experimental, even within Google. (I have been
dealing with other stuff that has delayed it.)

In short, I wouldn't worry about Snap Start in this scope. If we
wished to be able to do it, unseen, with data from TLS then we would
need the server's certificate, as well as knowledge about its exact
behaviour in response to TLS extensions. In the interests of size, we
would probably define the extension behaviour precisely and publish an
ECDH point in DNS. Then we could define the X509 gubbins around the
ECDH public key.

But Snap Start is already terribly complex so let's see if the
performance data justifies it first :)

Cheers

AGL

---

From: James Cloos <[email-masked]>
Date: Fri, 17 Dec 2010 16:27:15 -0500

>>>>> "MM" == Matt McCutchen <[email-masked]> writes:

>> For that to work, a lack of dns trust has to fall back to the collection

MM> And that works fine when the client gets a "secure" DNSSEC result with
MM> zero TLSA records or an "insecure" result.  On the other hand, a "bogus"
MM> result means the system is misconfigured or under attack.  I don't see
MM> why there is a demand that the system continue to function in such an event.

Unless the client previously noted that a given remote uses DANE, how
can it tell that a non-secure DNS lookup is a MITM attack and not just
a legacy site?

-JimC

---

From: Steve Schultze <[email-masked]>
Date: Fri, 17 Dec 2010 18:55:40 -0500

> can it tell that a non-secure DNS lookup is a MITM attack and not just

It can't.  According to Matt's suggested text:

'...if any query gives an "insecure" or "indeterminate" result, KIDNS cannot be used with this TLS server, and the client MAY use an alternative certificate validation method.'

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 18 Dec 2010 00:32:34 -0500

On Fri, 2010-12-17 at 18:55 -0500, Steve Schultze wrote:
> '...if any query gives an "insecure" or "indeterminate" result, KIDNS
> cannot be used with this TLS server, and the client MAY use an
> alternative certificate validation method.'

It can, because legacy sites have a NSEC for the DS record in the parent
zone.  That was our point here:

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

-- 
Matt

---

From: James Cloos <[email-masked]>
Date: Sat, 18 Dec 2010 12:54:25 -0500

>>> Unless the client previously noted that a given remote uses DANE,
>>> how can it tell that a non-secure DNS lookup is a MITM attack and
>>> not just a legacy site?
>> 

Which of course was my point. ☺

MM> It can, because legacy sites have a NSEC for the DS record in the
MM> parent zone.  That was our point here:

MM> http://www.ietf.org/mail-archive/web/keyassure/current/msg01196.html

Why do you think that a MITM would only munge a child zone and not also
its parents?

-JimC

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 18 Dec 2010 13:13:22 -0500

> Why do you think that a MITM would only munge a child zone and not also

By configuring a trust anchor for the root zone, you are telling the
client to demand that the zone be signed with that key.  It will not
allow the entire DNSSEC to be downgraded away.  For it to accept a site
as legacy ("insecure"), there must be an NSEC for DS somewhere above the
site that chains to the trust anchor.

This is basic DNSSEC stuff explained in RFC 4033.  I would rather not
keep rehashing it here.

-- 
Matt

---

From: Jakob Schlyter <[email-masked]>
Date: Sun, 19 Dec 2010 00:05:44 +0100

> to get enough information about the pubkey used on a website.

You could make both queries in parallel, so I would not say this is a big problem.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 19 Dec 2010 00:12:33 +0000

Make it work first.

Only optimize after you make it work.

The number of DNS round trips should be out of scope, not the functionality
necessary to do the necessary job.

I can fix the number of round trips to one, but we simply should not
consider it at this point.

On Sat, Dec 18, 2010 at 11:05 PM, Jakob Schlyter <[email-masked]> wrote:

> > But we have no method defined anyway to get all this information at once.
> So now this becomes two full roundtrip DNS queries

---

From: Paul Wouters <[email-masked]>
Date: Sun, 19 Dec 2010 17:35:57 -0500 (EST)

> It's a thought, but one that has not garnered much interest in the past.

So am I right that the consensus seems to be to continue with TLSA and HASTLS now, and look into
an EDNS method later to optimise?

I would be okay with that, and willing to take on the EDNS work to produce a draft. But I would
also really like to see a "pubkey only" type being added to the TLSA draft to satisfy those who
do not want to deal with any certificate information. This might go a long way to make TLSA a
complete solution for those who want to minimize and maximize CA/cert usage. And would probably
be enough to avoid Kaminsky/Gilmore and co to not deploy more TXT record overloads.

> Because the "this host serves TLS and non-TLS" and "when we serve TLS, this is the key we will use" semantics are orthogonal. Having orthogonal semantics in the same record often leads to implement…

Understood. I'll worry about the optimisation step later.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 19 Dec 2010 17:42:57 -0500 (EST)

> Probably not. That is, if the user is not going to TLS (because the server doesn't do TLS or a MITM has done a downgrade to non-TLS), they should not be looking for TLSA records.

That would suggest an implicit policy of "If a TLSA record exists, only do https". If that
is meant, you should state so in the draft? right now, there is an implicit "http first, perhaps https later".

> The attack you are concerned with is being dealt with in the WEBSEC WG (for the HTTP case) and hopefully by draft-hoffman-server-has-tls (depending on how the WEBSEC WG moves forwards).

The key issue here is the decision point to do "https only". If you make that after connecting to http,
then moxie's attack can change the http traffic to remove any sign for "must go to https". So anything
on port 80 cannot give us authenticated proof to only use port 443. An out of bound DNSSEC validated
record can.

Which is why I'm suggesting the policy of "if TLSA, then only do https". Or at least "start with https"
to allow for (not recommended) https/http mixed content.

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 19 Dec 2010 18:12:34 -0500

> on port 80 cannot give us authenticated proof to only use port 443. An out of bound DNSSEC validated

Right.

> to allow for (not recommended) https/http mixed content.

A separate record would be better design as Paul Hoffman has explained.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 19 Dec 2010 18:14:05 -0500

On Sun, 2010-12-19 at 17:35 -0500, Paul Wouters wrote:
> But I would
> complete solution for those who want to minimize and maximize CA/cert usage.

How much will that help, given that TLS itself requires a certificate?
(Or do you propose a new TLS certificate type of "bare public key"?)

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Sun, 19 Dec 2010 18:32:48 -0500 (EST)

> A separate record would be better design as Paul Hoffman has explained.

I'd argue that you'll find different implementations, where some do and
some don't treat the TLSA as a "policy" to start with https - because
frankly it makes no sense to publish a TLSA record and still have https
as an "optional" on your site. It does not prevent the SSLstrip attack,
and I'd rather not advocate people implement TLSA without "must do
https first".

If people do insist on a "policy record", next to TLSA and HASTLS, has
any work been done on such a policy record? If this policy record would
be missing when TLSA and HASTLS reach RFC, implementations surely will
treat the presence of any of these records as a policy of "https only".

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 19 Dec 2010 18:37:54 -0500 (EST)

> (Or do you propose a new TLS certificate type of "bare public key"?)

Correct. A meaning of "only take the public key, and nothing else". I find
that option is missing currently from draft-ietf-dane-protocol-00.txt, which
only states:

          1 -- Hash of an end-entity certificate
          2 -- Full end-entity certificate
          3 -- Hash of an certification authority's certificate
          4 -- Full certification authority's certificate

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 19 Dec 2010 19:10:14 -0500

> and I'd rather not advocate people implement TLSA without "must do

Implementations that do are just plain wrong.  Not every site today is
interested in preventing the sslstrip attack.  Sites should be able to
use TLSA for its intended purpose of modifying the set of acceptable TLS
certificates without getting this side effect.

> treat the presence of any of these records as a policy of "https only".

HASTLS is the "policy record".  The server just advertises that it
offers the protocol only over TLS, and HASTLS-aware clients will not try
the non-TLS version.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 19 Dec 2010 19:15:24 -0500

>           4 -- Full certification authority's certificate

I'm not sure you understood what I meant.  The TLS protocol with server
authentication requires a Certificate message, which can contain an
X.509 certificate or a "certificate" of some other type negotiated via
the cert_type extension (RFC 5081).  So unless a new certificate type of
"bare public key" is added to TLS, the server has to send a certificate.
What do you gain by publishing the public key in TLSA rather than that
certificate?

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Dec 2010 04:00:27 -0500 (EST)

> offers the protocol only over TLS, and HASTLS-aware clients will not try

But draft-hoffman-server-has-tls states:

 	The HASTLS resource record type, whose value is TBD1, lists all of
 	the pairs of insecure/secure port pairs that are served on the host
 	named by the domain name.

Which means that to support clients without TLSA/HASTLS suport (every
web browser), while protecting clients with TLSA/HASTLS support from
ssltrip attacks (a practical, not theoretical attack), I need to lie in
my HASTLS record and state I'm not running on port 80.

I believe it would be better of we devise a scheme where one does not have
to lie in new RRTYPE's to give validated DNSSEC protection for new
clients and keeping backwards compatibily for older clients. Especially
because port 80 is not going away overnight.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Dec 2010 04:11:30 -0500 (EST)

> What do you gain by publishing the public key in TLSA rather than that

1) A validated message stating that the DNSSEC trust model is used, and no
    CA/PKIX based trust model should ever be attempted on this host/service

2) Reduced play room for attackers to launch (pre)image attacks against the public
    key for those not interested in CA/PKIX based trust model. By only hashing the
    key there is a lot less room to play with then if fields like CN= and O= would
    be part of the hash

3) Reduced attack room in parsing invalid/bogus CA/PKIX certificate properties
    (if we define the new type to may only contain the minimum required X.509 fields)
    I'm thinking here of badly place \0 values and ASN.1 parser errors.

3) As you brought up, perhaps support for a future "bare public key" TLS type
    that operates purely on DNSSEC validation without any CA/PKIX.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Dec 2010 11:35:36 +0000

On Sun, Dec 19, 2010 at 10:35 PM, Paul Wouters <[email-masked]> wrote:

>> Not at all. If you are about to do TLS and only TLS, then you don't need
>> to query for HASTLS: it is only if you want to do TLS but cannot get there
>> that you need to do HASTLS.
>>

That was definitely the sense I got from the remote feed of the WEBSEC WG.

Their problem with strict security divides into two. The first is how to
signal that strict security is to be employed. The second is to define what
strict security is and how it should affect browser security. The first
problem is fairly straightforward, the second is hard.

I think it makes a lot of sense to do the HTTP header approach as an interim
measure. But in the long term the signaling mechanism for the Internet is
DNS.

Here is how I see squaring the circle:

I see a three layer scheme that allows for protocol information to be
expressed with increasing specificity as discovery progresses.

RR-A
    Expresses information that binds to the entire domain.
    Is never the target of a prefixed query
    May be wildcarded, resolution may be aliased.
    May have a flag to state 'use SRV/URI/NAPTR discovery' and continue the
discovery chain

RR-B
    Expresses information that binds to a specific protocol or a specific
host/protocol
    Is always prefixed using a protocol prefix
    Must not be wildcarded.
    Resolution is always for a known canonical name
    Protocol level record may have a flag to state that there is yet more
detail at the host level.

So a simple RR set might be:

$origin example.com
www           CNAME example.com
.             RR-A  "Root cert is X"

A more detailed RR set might be:
$origin example.com
www           CNAME example.com
.             RR-A  "Root cert is X"
.             RR-A  "Protocol detail"
_http._tcp    RR-B  "Always use TLS"

Here the discovery chain starting from either www.example.com or
example.comwill result in the client collecting the pair of RR-As and
then make a
second, protocol specific lookup for the RR-B.

The reason that two separate RRs are needed here is that a RR type can be
used with wildcards or with prefixes but not both.

A yet more detailed version would introduce SRV or URI discovery (I am not a
fan of NAPTR).

$origin example.com
www           CNAME example.com
.             RR-A  "Root cert is X"
.             RR-A  "SRV Discovery"
.             RR-A  "Host detail
_http._tcp    SRV   1 1 443 h1.example.com
_http._tcp    SRV   1 1 443 h2.example.com
_http._tcp.h1 RR-B  "Always use TLS"
_http._tcp.h1 RR-B  "EE key is Y"
_http._tcp.h2 RR-B  "Always use TLS"
_http._tcp.h2 RR-B  "EE key is Z"

Since we are using SRV discovery with meta-discovery here, there are
inescapably three separate names that will be queried; general, protocol and
host. There are a minimum of three round trips unless we introduce a
meta-discovery mechanism.

One possibility here is that servers automatically know that they need to
push out the entire RR chain as additional records when a RR-A query is
made. That fails in the general case as the protocol prefix is required for
resolution.

I would prefer a new meta query record that the server advertises support
for. This would be advertised as being supported using EDNS0 and would take
an extensible tag-value separated list of properties.

MEGA-Q  www.example.com _http._tcp
    source-ip = 10.1.1.1
    ipv6=yes

The reason for these additional parameter slots is that I would like to
introduce new and better discovery mechanisms over time.

The main point of comparison here is to the NAPTR DDS scheme. The difference
in my mind is that NAPTR introduces Regular Expressions and my scheme does
not. I think evaluating REs is too powerful a tool at this layer in the
stack. They are tantamount to being a Turing complete programming language.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Dec 2010 12:00:59 +0000

On Sun, Dec 19, 2010 at 10:42 PM, Paul Wouters <[email-masked]> wrote:

>> Probably not. That is, if the user is not going to TLS (because the server
>> doesn't do TLS or a MITM has done a downgrade to non-TLS), they should not
>> be looking for TLSA records.
>>
>

I don't like implicit policy.

First off, the TLSA record is not specific to the HTTP protocol. So does
putting up a TLSA record imply strict security for IMAP, POP?

But policy is what this whole project should be about. Right now we have a
situation where security is the exception. We need to change that to a
situation where security is the default. Or rather where minimal security in
the form of encryption and authentication anchored to the DNS name is the
default.

Without a policy layer it will be ten years before people can use DNSSEC
validated keys in any case.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 20 Dec 2010 12:44:31 +0000

> But what does "ignored" mean?  Does it mean the client must give an "access_denied" error?  If so, you fall into the second of my two traps.

No. Your second trap is fallacious: the majority of sites will not be
DNSSEC enabled and therefore an unsigned response is expected.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Dec 2010 08:54:15 -0800

>   that operates purely on DNSSEC validation without any CA/PKIX.

Just to be clear: are you are proposing DANE adding "bare public key" *before* any version of TLS allows that? That means that DANE will be changing the TLS semantics for all current versions of TLS. It is possible we could do that, but that seems a bit daunting given the low value of the first three items on your list.

In specific, your #1 is "you must use what I am telling you regardless of your policy", and the WG has not decided it wants to do that. There was wide disagreement during our BoF phase, and we have not had a consensus call on this yet. Further, if we did decide we want to do that, it could be achieved with a flag, not with a change to TLS.

Your #2 and #2 are, in my opinion, FUD. If there is a preimage attack on a signature algorithm, it affects much more than just the signature used in the TLSA record: it affects both DNSSEC and TLS as well. Using preimage strength of one tiny part of a system as an argument for us changing TLS is false security. Similarly, if you think TLS is open to error attacks from PKIX, change TLS. You haven't tried to do so (at least from my brief review of the TLS WG archives), and trying to do it through DANE seems really inappropriate.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Dec 2010 09:00:41 -0800

>my HASTLS record and state I'm not running on port 80.

I don't see how you got to that conclusion; can you state it again? I think the first clause is irrelevant: if they do not support either record type, you don't need to do anything different in HASTLS. If you are running a server on port 80, you *cannot* prevent ssslstrip attacks: that is the whole point of the HASTLS document.

>because port 80 is not going away overnight.

No one has suggested lying in any DNS record; please be clearer about your assumptions and the attack.

--Paul Hoffman, Director
--VPN Consortium

---

From: Steve Schultze <[email-masked]>
Date: Mon, 20 Dec 2010 13:10:44 -0500

> DNSSEC enabled and therefore an unsigned response is expected.

Ok, presuming Matt's text (which I think is good):
http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html

"...if any query gives an "insecure" or "indeterminate" result,
KIDNS cannot be used with this TLS server, and the client MAY use an
alternative certificate validation method."

My point is simple: it is good to have MAY above rather than MUST
or MUST NOT.  This allows the client to decide whether or not PKIX is 
"good enough" in the case in which the server has not yet implemented 
DANE.  Early on, clients may choose not to require a matching TLSA 
record when DNSSEC or DANE are not widely deployed.  A security-
conscious client might eventually choose to require a matching TLSA 
record.  At that point, even if a given domain is not DNSSEC enabled
and an unsigned record is expected, the client may not deem it good
enough.

As Matt's text helps to make explicit, there are two points at which the
client MAY choose to fall back on PKIX:
1) Non-DNSSEC secured domains
2) DNSSEC-secured domains that do not have a matching TLSA record

I should note that when I said earlier in the thread "But what if the MITM 
overrides the genuine DNSSEC-signed record with a record that is not 
signed with DNSSEC?  Is there some reason why this is not possible?"
I didn't understand that DNSSEC would be giving a result of "bogus",
which I admitted here:
http://www.ietf.org/mail-archive/web/keyassure/current/msg01197.html

Thus, this is all a question what the domain operators have implemented
rather than a MITM scenario.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Dec 2010 13:18:14 -0500 (EST)

> Just to be clear: are you are proposing DANE adding "bare public key" *before* any version of TLS allows that? That means that DANE will be changing the TLS semantics for all current versions of TL…

Is there a technical reason why it can't?

> In specific, your #1 is "you must use what I am telling you regardless of your policy", and the WG has not decided it wants to do that. There was wide disagreement during our BoF phase, and we have…

But you now have policy enforced too, namely the certificate contents,
such as CN= or O= or Expiry etc.  And they bring in a whole branch of
dependancies on non-DNSSEC trust.

>From what I understood from browser vendors, is that it is important
that non-validated data is limited because it does not fit well into
their model. So a CN= that is not validated will fail to skip the
CA validation chain.  Having an explicite type that allows them to
pick just the public key and nothing else would help tremendously.
Whether you call this "policy" or not is somewhat semantec.

> Your #2 and #2 are, in my opinion, FUD. If there is a preimage attack on a signature algorithm, it affects much more than just the signature used in the TLSA record: it affects both DNSSEC and TLS…

What I was referring to the attack class from the md5 rapidssl hack from
CCC two years ago

https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php
http://www.win.tue.nl/hashclash/rogue-ca/

Yes, this one got plugged, but why have DNSSEC based trust exposed to
these kind of attacks at all?

DANE/keyassure is about using DNSSEC for trust, alongside fixing up the
PKIX model by reducing some weaknesses addressed by proposals such as
the CAA record and draft-saintandre-tls-server-id-check-12.

I don't agree with you calling DNSSEC related issues "policy" but not
applying the same words to PKIX related matters. Isn't making a distiction
between type 2 and type 4 a policy?

Paul

---

From: Steve Schultze <[email-masked]>
Date: Mon, 20 Dec 2010 13:18:47 -0500

On Dec 18, 2010, at 1:13 PM, Matt McCutchen wrote:
>>>> SS> It can't.  According to Matt's suggested text:
>> 

Yes, it is not possible to MITM at the DNSSEC layer by removing DNSSEC
validation (as I now  understand).  However, if you presume that the
domain truly is not DNSSEC secured, then one can certainly MITM the site
by substituting rogue PKIX credentials.  In the case of a DNSSEC result
that gives an "insecure" result, the client can be sure that the zone is
not DNSSEC secured (because there was an NSEC for DS somewhere above
that zone), but it cannot know that it is not being PKIX MITM'ed. Perhaps this 
was self-evident to everybody already given that it's largely the reason that this 
WG exists. ;)

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Dec 2010 13:24:59 -0500 (EST)

> I don't see how you got to that conclusion; can you state it again? I think the first clause is irrelevant: if they do not support either record type, you don't need to do anything different in HAS…

- for clients not supporting HASTLS/TLSA, we can do nothing to prevent sslstrip
- for clients supporting HASTLS/TLSA, we can prevent sslstrip, if we can convey
   this by either the presence of HAS/TLSA or an option in those records.

It would be a common deployment to leave port 80 running for old clients not supporting
these records to continue to work (and be vulnerable to sslstrip)

It would be highly desirable that we can have new clients protected from sslstrip
even if we are forced to leave port 80 on in the forseeable future to support
older clients.

We would need to signal to new clients "ignore unseured port".

A current "hack" would be to specify "0 443", while in fact keeping things running on port 80.
This would tell new clients to never fallback on port 80, while older clients could still use
it (while of course remaining vulnerable to sslstrip)

My proposal was for some kind of change to formalise this, so that the most common deployment
would not be something not part of the original design (the lying about port 80)

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Dec 2010 10:32:47 -0800

>Is there a technical reason why it can't?

I don't think so. I said "daunting" because having a new WG like DANE say "we're changing the semantics of all existing versions of TLS" is procedurally, er, interesting.

>dependancies on non-DNSSEC trust.

If we choose to go the "you must use what I am telling you regardless of your policy" route, and do it with a flag instead of an inherent policy, there no more semantics to the PKIX certificate.

>Whether you call this "policy" or not is somewhat semantec.

Using PKIX certificates for TLS is a "policy" that every vendor that uses TLS has chosen to do already.

>http://www.win.tue.nl/hashclash/rogue-ca/

You said "preimage", and this is a collision-reduction attack, so I misunderstood what you were talking about. Now, instead of a preimage attack, you are talking about trying to prevent careless (and/or clueless) CAs in your trust anchor pile from doing the wrong thing. That is a completely different attack, one that no protocol that has trust anchors (including DNSSEC!) can prevent.

>these kind of attacks at all?

Your proposed solution doesn't prevent the attack: it just (silently) shifts it to the DNSSEC chain.

>between type 2 and type 4 a policy?

You are mixing up two different policies. The one I said this WG had not dealt with is "you must do what I say"; the one you are talking about in PKIX is "your trust anchor pile is out of control".

--Paul Hoffman, Director
--VPN Consortium

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 20 Dec 2010 19:59:33 +0100

Hi Steve,

> 2) DNSSEC-secured domains that do not have a matching TLSA record

I want to split 2 into two parts.
2.1) DNSSEC-secured domains that have zero TLSA records.
2.2) DNSSEC-secured domains that have non-matching TLSA records.

2.1 MAY choose to fall back on PKIX.
2.2 MUST be access denied, otherwise you have a 'downgrade to PKIX'.

And yes, in DNSSEC you can securely detect that there are 0 records.

> rather than a MITM scenario.

So, an operator can 'opt-in' by deploying DNSSEC-signed TLSA records.

Best regards,
   Wouter

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 20 Dec 2010 11:35:42 -0800

On Mon, Dec 20, 2010 at 10:24 AM, Paul Wouters <[email-masked]> wrote:
>> ... If you are running
>> a server on port 80, you *cannot* prevent ssslstrip attacks: that is the
>> whole point of the HASTLS document.
>
> - for clients supporting HASTLS/TLSA, we can prevent sslstrip, if we can
>   convey this by either the presence of HAS/TLSA or an option in those records.
>
> It would be a common deployment to leave port 80 running for old clients not
> supporting  these records to continue to work (and be vulnerable to sslstrip)

Why would you not simply turn off port 80?  Users of older clients
would have to manually type https://, and inbound links might break,
but I don't see any other negative consequences.

zw

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Dec 2010 11:43:18 -0800

>We would need to signal to new clients "ignore unseured port".

This, again, is you saying to a client "I could care less what your policy is, you must do what I say". That's a model of security that has not been widely accepted, to say the least.

>it (while of course remaining vulnerable to sslstrip)

...and that goes directly against the purpose of the expanded semantics of HASTLS over the current draft of HSTS: it tells the client in a secure fashion what is reality and assumes that the client will use the client's policy in the face of known reality.

>would not be something not part of the original design (the lying about port 80)

You can propose lying; I would object and instead continue to propose honesty. It really comes down to that.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Dec 2010 15:21:46 -0500 (EST)

> This, again, is you saying to a client "I could care less what your policy is, you must do what I say". That's a model of security that has not been widely accepted, to say the least.

How is that different from telling the client what SSL version, ciphers,
keysizes, hashing algos are accepted for a specific TLS connection? See
port 80 as "SSL0, null cipher, hash md5, keysize 0" :P

> ...and that goes directly against the purpose of the expanded semantics of HASTLS over the current draft of HSTS: it tells the client in a secure fashion what is reality and assumes that the client…

Then give me an alternative to accomplish protection against
sslstrip. HSTS does not do any good because the attacker can perform a
MITM by taking in the clients HTTP and starting its own HTTPS to the
remote server, and mangle/attack everything. You cannot really leave
this attack out of scope.

> You can propose lying; I would object and instead continue to propose honesty. It really comes down to that.

How do we protect the user that implements DANE protocols from
sslstrip? For this exercise, you may not use PKIX based trust.

It's an obvious hole in the drafts.  I've made suggestions you don't
like. Your only alternative offered has been a "design a totally new draft
for that". Your objection is based on "DNSSEC cannot dictate policy, only
PKIX may do that".  Yet DANE is meant to provide an alternative to PKIX.

If we can't even use these new drafts to protect browsers, why ARE we
writing new drafts?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Dec 2010 12:22:58 -0800

>but I don't see any other negative consequences.

If the client doesn't have the right trust anchor, they will get dire warnings and possibly be prevented from getting to the site. This is a prime motivator for the DANE work.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Dec 2010 15:26:58 -0500 (EST)

> I don't think so. I said "daunting" because having a new WG like DANE say "we're changing the semantics of all existing versions of TLS" is procedurally, er, interesting.

Okay. How about adding a private use type so we have something to code
against while we look into adding a new "bare public key" option to TLS?

> Using PKIX certificates for TLS is a "policy" that every vendor that uses TLS has chosen to do already.

We could limit the flag/option to the non-PKIX case? So we would in no
way alter the policy of PKIX as implemented to date.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Dec 2010 15:30:23 -0500 (EST)

> but I don't see any other negative consequences.

You are suggesting breaking everyone's browser. That seems like the worst
thing we can do. DANE is about reducing errors to users, not adding to them.

It also implies users are aware of http vs https. They should not need to be.

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 20 Dec 2010 15:32:22 -0500

> but I don't see any other negative consequences.

Those are pretty significant consequences!  I'd imagine the last thing a
major online business wants is for a significant fraction of its
customers to suddenly get an error page when they type in the name of
the site.  It would take a massive PR effort to get everyone to upgrade
their browsers or type https: .  Yes, that's eventually needed anyway to
realize the security benefits, but for now I strongly prefer a scheme
that can be adopted without breaking legacy clients.  (Perhaps the
PayPal folks would offer their perspective?)

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Dec 2010 20:50:17 +0000

Must use TLS is only one use case and not necessarily the most interesting.

TLS is always offered is rather more interesting to me. Particularly when
combined with lightweight DNSSEC validated keys.

As of today 0% of browsers support DANE. And it will be ten years or so
before the proportion supporting DANE is above 90%. If all DANE offers is a
'cheap' substitute for CA issued certs it is probably going to fail. Who is
going to deploy such a scheme at a server? It is certainly not going to work
for any commercial application that requires security since nobody is going
to accept a 10% drop in sales as the price of using a 'free' cert.

Now consider what is possible when a site has a way of saying 'TLS is always
offered, here is the key'.

Deployment now becomes a no-downside option for any server which would not
normally have used security.

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 20 Dec 2010 13:50:41 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Matt McCutchen
> > >
> > > It would be a common deployment to leave port 80 running for old
> > > clients not supporting  these records to continue to work (and be
> > > vulnerable to sslstrip)
> >

Actually, you'd shut off tons of traffic to your site.  I don't have total numbers, but I can try to get them.

> Those are pretty significant consequences!  I'd imagine the last thing a major
> online business wants is for a significant fraction of its customers to suddenly
> get an error page when they type in the name of the site.  It would take a
> massive PR effort to get everyone to upgrade their browsers or type https: .
> Yes, that's eventually needed anyway to realize the security benefits, but for
> now I strongly prefer a scheme that can be adopted without breaking legacy
> clients.  (Perhaps the PayPal folks would offer their perspective?)

Since you asked :)

1. The current HSTS header isn't a problem for clients that don't understand it.

2. The current design does require potentially insecure bootstrapping.  We're well aware of that. We wanted it out there sooner rather than later to protect better than was currently possible against sslstrip-type attacks.  With a proper max-age parameter, you're pretty safe against sslstrip if your whole site is HTTPS, *and* users don't get attacked  (MITM)the first time they visit you.  In advance of the DNSSEC approach, Google also has the STS-preloaded list stuffed into Chrome, and www.paypal.com is on the list.

3. We don't want to shut off legacy clients that don't understand HSTS, so we have to leave port-80 running. We try very hard though to only redirect to HTTPS from HTTP, and never serve any content over HTTP.

4. Somewhere in a previous thread was the suggestion of browses simply trying port-443 first, and only if they don't get a response to downgrade.  The problem here is than an active attacker can spoof the RST for port-443, and then MITM port-80.

5. Most of our links in search engines also show as HTTPS these days, so a lot of traffic doesn't come over port-80 anymore.  I wish I had some statistics though.

6. As long as I'm randomly brain-dumping, OOB STS policy delivery helps to solve the slight privacy problem currently present with HSTS.  A server can detect whether it has seen you before by testing whether you have HSTS in effect for a given domain. With OOB signaling, we avoid this bootstrapping problem, though I suppose if clients cache they can still have a problem.  Privacy-mode though doesn't have to cache anymore, but can still get HSTS benefits, and non-private mode can cache for performance reasons if necessary.

Sorry for the brain-dump, I was on vacation for a week and just catching up...

- Andy

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 20 Dec 2010 15:52:47 -0500

On Mon, 2010-12-20 at 15:30 -0500, Paul Wouters wrote:
> DANE is about reducing errors to users, not adding to them.

Mmm... there's not much of an excuse for errors now, with at least one
public CA offering certificates free of charge.  Why some site admins
are happy to register with ICANN but claim a philosophical objection to
getting a free cert from a public CA is beyond me.  Though for large
organizations, DANE may be more convenient than requesting lots of
certificates individually from a public CA.

The major draw for me is to not be exposed to the public CAs.

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Dec 2010 16:05:10 -0500 (EST)

On Mon, 20 Dec 2010, Phillip Hallam-Baker wrote:

> As of today 0% of browsers support DANE. And it will be ten years or so before the proportion supporting DANE is
> above 90%.

I've talked to one major browser vendor and with our help they want
to try and get it into their next major release. Which would be in the
order of 3-6 months. Not 10 years.

> Now consider what is possible when a site has a way of saying 'TLS is always offered, here is the key'. 
> 
> Deployment now becomes a no-downside option for any server which would not normally have used security. 

Indeed. And deployment can go up dramatically as well if we can work around the hostname/CN= limitation
of SSL, hence the desire for a "bare public key" as well.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Dec 2010 16:41:09 -0500 (EST)

On Mon, 20 Dec 2010, Phillip Hallam-Baker wrote:

> Just wrap the key in an X.509 self signed cert and it is done.
> 
> I don't see why you think this is an issue.

My self signed cert containing CN=www.paypal.com

Browser vendors do not want to display that when there was a self signed
cert without CA/EV backing and only the pubkey was validated via DNSSEC.

So it would have to be a very specific kind of self signed cert to
pass. Instead of adding X.509 policy on the various certificate bits that
SHOULD NOT be used for DNSSEC validated self-signed certs, I proposed the
"ignore all these bits and treat as a "bare public key". This means no
CN= would ever reach the enduser.

Paul

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 20 Dec 2010 14:42:58 -0700

> Behalf Of Paul Wouters
> So it would have to be a very specific kind of self signed cert to pass. Instead
> of adding X.509 policy on the various certificate bits that SHOULD NOT be
> used for DNSSEC validated self-signed certs, I proposed the "ignore all these
> bits and treat as a "bare public key". This means no CN= would ever reach the
> enduser.

What do you mean "reach the end user"?  

1. Show up in the location bar?
2. Show up when I click "certificate details"?
3. Something else?

- Andy

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Dec 2010 16:51:02 -0500 (EST)

> 2. Show up when I click "certificate details"?

The browser vendor CA policy does or will have constraints that prevent
unvalidated information from being present in all CA-issued certificates.

They highly recommend being consistent with that policy to clear 
DNSSEC-based cert chain validation for inclusion in their browser.

In fact, I was lit. told:

 	That means the cert shouldn't contain anything
 	except (roughly) the key and key usage restrictions. I do not
 	understand why you would want to allow any more (AFAICT,
 	useless and/or misleading) information in the cert anyway.

I am not sure what incompatibilities it would create if we would now have
certificates with an empty CN=. How do current browers deal with that? To
prevent interoperability issues and implementation differences, I suggested
using a TLSA type that explicitely states this goal.

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 20 Dec 2010 16:55:59 -0500

> 2.1 MAY choose to fall back on PKIX.

Correct.

> 2.2 MUST be access denied, otherwise you have a 'downgrade to PKIX'.

Correct, assuming the TLSA records are exclusive.  Phillip has argued
that it should be possible to use TLSA non-exclusively.  I don't find
the example of two protocols on the same host compelling (the right way
to handle that is to put the TLSA at a name specific to the protocol),
but it seems easy enough to have a flag, unless there's an argument that
doing so is harmful.

> So, an operator can 'opt-in' by deploying DNSSEC-signed TLSA records.

Exactly.

-- 
Matt

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 20 Dec 2010 14:59:31 -0700

> From: Paul Wouters [mailto:[email-masked]]
> 

OK, but in this case what if it isn't CA-issued?
 
> using a TLSA type that explicitely states this goal.

Sure. This makes some decent sense.  At the same time, we have two "choices".

1. TLSA records make the cert itself a trust-anchor, or chained off the DNS Root (or some other)
2. TLSA records aren't signed by a CA, but can be trusted to safely bootstrap TLS.

In the case of #2 btw, where we have raw public keys, what is the impact on SNI?  In some cases having "raw" public keys lets us avoid SNI, because the same virtual host can present the same public key for all virtual hosts, advertise them in DNS, but not need SNI.  Especially if we don't have to do usual PKIX validation, like checking CN, or following any/all of the rules in http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-12

- Andy

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 20 Dec 2010 17:08:42 -0500

> of SSL, hence the desire for a "bare public key" as well.

My understanding is that DANE does not care about the server names in
end-entity certificates designated by associations of type 1 or 2.
Obviously it needs to care for type 3 or 4.  This needs clarification in
the draft, but assuming my understanding is correct, there is no issue
that would be a reason to use bare public keys.

-- 
Matt

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Dec 2010 17:15:22 -0500

>>>>> "Paul" == Paul Wouters <[email-masked]> writes:

    Paul> My self signed cert containing CN=www.paypal.com

    Paul> Browser vendors do not want to display that when there was a self signed
    Paul> cert without CA/EV backing and only the pubkey was validated via DNSSEC.

    Paul> So it would have to be a very specific kind of self signed cert to
    Paul> pass. Instead of adding X.509 policy on the various certificate bits that
    Paul> SHOULD NOT be used for DNSSEC validated self-signed certs, I proposed the
    Paul> "ignore all these bits and treat as a "bare public key". This means no
    Paul> CN= would ever reach the enduser.

+1

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 20 Dec 2010 17:34:08 -0500

On Mon, 2010-12-20 at 14:59 -0700, Steingruebl, Andy wrote:
> In the case of #2 btw, where we have raw public keys, what is the
> impact on SNI?  In some cases having "raw" public keys lets us avoid
> SNI, because the same virtual host can present the same public key for
> all virtual hosts, advertise them in DNS, but not need SNI. 

Agreed, the issue of not knowing which certificate to present among
mutually trusting sites on the same server goes away.  There are still
some uses for SNI:

- SNI makes it possible for a frontend to distribute connections
requesting different server names to different backends without
terminating TLS.  The backends could even be mutually untrusting with
different public keys.  Granted, SNI may not have been intended to
support this use case.

- SNI makes it possible to catch diversion of a connection by a MITM to
a server that has credentials valid for the requested site but does not
intend to serve it at the TLS level.  Otherwise, the job falls to the
application, and the error reporting is not as clean.  See:

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

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Dec 2010 15:08:27 -0800

>against while we look into adding a new "bare public key" option to TLS?

Using DANE as an end-run around the TLS extension process is one possibility: actually doing the work for a TLS extension is another.

>way alter the policy of PKIX as implemented to date.

That would be fine.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Dec 2010 15:11:44 -0800

At 3:21 PM -0500 12/20/10, Paul Wouters wrote:
>sslstrip?

With HASTLS.

>For this exercise, you may not use PKIX based trust.

Not needed if you have DANE.

>PKIX may do that".  Yet DANE is meant to provide an alternative to PKIX.

No, it isn't. It is meant to provide security services that the current TLS model does not handle.

>If we can't even use these new drafts to protect browsers, why ARE we

So that you can start spouting hyperbole instead of doing hard security work?

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Dec 2010 23:52:40 +0000

While you might find the requirement for two protocols on one DNS name to
not be compelling, it happens to be the way the Internet was designed, is
today and will be even more so in the future.

What is the compelling reason for taking an approach that is known to be
broken now when there is an alternative on the table that meets all the
requirements?

These are really not difficult problems to solve when people are prepared to
actually recognize them as problems. We seem to be fitting the problem to
the chosen technology, not looking at the problem and working out the best
way to solve it.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Dec 2010 00:05:04 +0000

And what do browsers do when a self-signed cert is presented today?

What you have there is a user interface issue. None of the positive claims
in a self-asserted key should be shown to the user in primary chrome under
any circumstance. [Negative claims such as restrictions on validity are
another matter]

This is already known.

Since people are going to insist on being able to use self-signed certs for
this purpose (and will ignore any DANE proposal if they are not supported),
what you are proposing is a new format that will only be used by the good
guys.

If browsers treat self-signed certs in idiot ways the risk you identify will
still exist. In fact this proposal makes it more likely the risk will be
realized by making it more likely browser authors think the problem is
solved.

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 20 Dec 2010 19:50:34 -0500

On Mon, 2010-12-20 at 23:52 +0000, Phillip Hallam-Baker wrote:
> While you might find the requirement for two protocols on one DNS name
> to not be compelling, it happens to be the way the Internet was
> designed, is today and will be even more so in the future.

You misunderstood me.  Keep both protocols at the same name, but do
something to the TLSA record to make it apply to only one protocol.
E.g., put the TLSA record at _smtp.example.com.  That, rather than
throwing away exclusivity, seems to be the solution proportionate to the
problem.

> What is the compelling reason for taking an approach that is known to
> be broken now when there is an alternative on the table that meets all
> the requirements?

If the alternative you mean is non-exclusive TLSA, it does not meet my
requirement to be able to make an exclusive statement that clients can
choose to honor and thereby no longer be exposed to the increasingly
unmanageable public CA system.

-- 
Matt

---

From: Geoff Beier <[email-masked]>
Date: Mon, 20 Dec 2010 19:51:40 -0500

> but I don't see any other negative consequences.
Wouldn't this just break the web for browsers that attempt to connect
to port 80 first in every case *except* when there's a MITM attacking
them? I see two scenarios if you just turn it off:

1. An old browser attempts to connect to port 80 under normal
circumstances. The user gets an error indicating that the site is
unavailable, and the web is broken unless that user is savvy enough to
type https and try again.

2. An old browser attempts to connect to port 80 in the presence of a
MITM attack. The MITM makes connections back to the real https server,
monkeys with the data, and sends it back to the user. The site appears
to work, and the attack is successful.

By my math, simply turning it offl leaves things apparently broken
when there's no attack and apparently functional when an attack is in
progress. That strikes me as the opposite of a desirable outcome, and
as a significant negative consequence.

Geoff

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 20 Dec 2010 17:42:43 -0800

> to work, and the attack is successful.

This is an excellent point, I withdraw my suggestion.

zw

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 20 Dec 2010 21:47:16 -0500

On Mon, 2010-12-20 at 11:43 -0800, Paul Hoffman wrote:
> This, again, is you saying to a client "I could care less what your
> policy is, you must do what I say". That's a model of security that
> has not been widely accepted, to say the least.
> 
> ...and that goes directly against the purpose of the expanded
> semantics of HASTLS over the current draft of HSTS: it tells the
> client in a secure fashion what is reality and assumes that the client
> will use the client's policy in the face of known reality.
> 

I would argue that if http://foo:80 is just a redirection to
https://foo:443, that is not really "service" in the sense envisioned by
draft-hoffman-server-has-tls and hence it is not a lie to specify "0
443".  The effect is really the same as that described for an SSO for a
protocol that uses in-band security update, except that the "band"
consists of two ports.

The more controversial case is when the server offers real service on
both http://example.com:80 and https://example.com:443 .  I think the
real question here is who gets blamed if the desired level of security
is not achieved.  In some cases there's only one party that can be
blamed (e.g., if one side leaks the master key or the client accepts an
invalid PKIX certificate or DNSSEC chain).  Beyond that, it's a gray
area and I'm having difficulty formulating any coherent statement, so I
will stop here.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 20 Dec 2010 22:05:52 -0500

> DNSSEC-based cert chain validation for inclusion in their browser.

This is the fallacy.  DANE is not a method of validating a certificate
as such, it is a method of determining the acceptability of a
certificate for a particular TLS server.  It replaces the combination of
PKIX chain validation + server ID check.

The browser should simply not show the irrelevant parts of a
DANE-endorsed certificate, unless it elects to also perform PKIX
validation against its trust anchor set and the validation succeeds.  I
don't think it makes sense to impose requirements on the whole Internet
for the sake of not having to refactor this browser's code.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 20 Dec 2010 22:27:48 -0500

On Tue, 2010-12-21 at 00:05 +0000, Phillip Hallam-Baker wrote:
> What you have there is a user interface issue. None of the positive
> claims in a self-asserted key should be shown to the user in primary
> chrome under any circumstance. [Negative claims such as restrictions
> on validity are another matter]
> 
> This is already known.
> 
> Since people are going to insist on being able to use self-signed
> certs for this purpose (and will ignore any DANE proposal if they are
> not supported),

[Side note: and why shouldn't they?  The point of this work is to take
advantage of the DNSSEC authority chain.  Why would one use a
public-CA-signed certificate with DANE for any reason other than EV or
compatibility with legacy clients?]

> what you are proposing is a new format that will only be used by the
> good guys.
> 
> If browsers treat self-signed certs in idiot ways the risk you
> identify will still exist. In fact this proposal makes it more likely
> the risk will be realized by making it more likely browser authors
> think the problem is solved.

Interesting point.  But the fact that security software is responsible
for defending against peers that don't act as they are supposed to is
widely recognized.  Either way, we call out the issue in the security
considerations, and then if the browsers mess it up, it is their fault.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 20 Dec 2010 23:07:44 -0500

On Mon, 2010-12-20 at 11:35 +0000, Phillip Hallam-Baker wrote:
> expressed with increasing specificity as discovery progresses. [...]

I like this scheme.  There are just some details to fill in:

- If information of the same type (e.g., TLSA) is specified at all three
stages, how is it combined?

- When TLSA of type 3 or 4 is used, what reference identifier(s) are
used for the server ID check?

- Early on, you pointed out that CERT RRs of existing types do not offer
an assurance and therefore we need something different.  The same is
true of CNAME.

> I would prefer a new meta query record that the server advertises
> support for. This would be advertised as being supported using EDNS0
> and would take an extensible tag-value separated list of properties.
> 
> 
> The reason for these additional parameter slots is that I would like
> to introduce new and better discovery mechanisms over time.

If we go this way, the (untrusted) DNS server will need to return all
the RRsets that it checked (or their NSECs) so the client can verify
that it executed the discovery process faithfully.  If the server is not
capable of returning everything the client wants, the client will end up
pulling individual RRsets to avoid being downgraded.  Still, we might
hope to eliminate a round trip or two in the common case.

(With an external resolver, these concerns apply only between the
resolver and the DNS server.)

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Dec 2010 20:30:52 -0800

At 9:47 PM -0500 12/20/10, Matt McCutchen wrote:
>443". 

It *is* a lie because you control the redirection. The semantics of "0 443" are "if you find a responder at port 80, it isn't me, and you are probably getting scammed". If, insetad, you announced "80 443" and did a redirect as above, it is not at all a lie.

>The effect is really the same as that described for an SSO for a

...and, as you say, something that is not a service.

>both http://example.com:80 and https://example.com:443 . 

Something on 80 that redirects to 443 *is* a real service in every sense of the word.

>I think the

The real question, one that will be addressed in both DANE and WEBSEC, is whether it is reasonable to say "I speak on port 80 but you MUST use 443 instead, even if you wanted to do port 80". If you can come up with non-silly semantics for that without obvious problems, the WGs might buy it. I'm skeptical, though; I see many reasons for a client to say "I know 443 is going to fail me, so I'm willing to fall back to 80". The most obvious example is "you're using a CA who I don't trust, so I'm going to fail during the TLS handshake".

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Dec 2010 00:22:12 -0500 (EST)

On Mon, 20 Dec 2010, Paul Hoffman wrote:

> The real question, one that will be addressed in both DANE and WEBSEC, is whether it is reasonable to say "I speak on port 80 but you MUST use 443 instead, even if you wanted to do port 80". If you can come up with non-silly semantics for that without obvious problems, the WGs might buy it. I'm skeptical, though; I see many reasons for a client to say "I know 443 is going to fail me, so I'm willing to fall back to 80".

You can't. sslstrip made that inheritantly unsafe.

> The most obvious example is "you're using a CA who I don't trust, so I'm going to fail during the TLS handshake".

How would a fallback in this case ever be safer? Either you are connecting
to the right host but are lacking proof, or you are connecting to
something malicious. In the first case, you're better of praying and
continuing then going to port 80 for which you have no identity proof
either. In the second case, going back to port 80 is not going to make
the attacker go away.

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 21 Dec 2010 00:43:36 -0500

On Mon, 2010-12-20 at 20:30 -0800, Paul Hoffman wrote:
> It *is* a lie because you control the redirection. The semantics of "0
> 443" are "if you find a responder at port 80, it isn't me, and you are
> probably getting scammed". If, insetad, you announced "80 443" and did
> a redirect as above, it is not at all a lie.

I guess you get to state the intended semantics of your draft, and then
I'm left to submit a different one.

> The real question, one that will be addressed in both DANE and WEBSEC,
> is whether it is reasonable to say "I speak on port 80 but you MUST
> use 443 instead, even if you wanted to do port 80". If you can come up
> with non-silly semantics for that without obvious problems, the WGs
> might buy it. I'm skeptical, though; I see many reasons for a client
> to say "I know 443 is going to fail me, so I'm willing to fall back to
> 80". The most obvious example is "you're using a CA who I don't trust,
> so I'm going to fail during the TLS handshake".

If http://foo:80 is just a redirection to https://foo:443, then it is
quite reasonable because all that falling back to http://foo:80 buys you
is the possibility of getting attacked.

Upon further reflection, I agree that when they both provide the
service, the MUST is not right.  The client can choose at its own risk.
The trouble is that most of the public is ill equipped to make this
choice and expects to be able to type mybank.com into a mainstream
browser and blame the browser or the site if anything bad happens.  So I
propose that the DNS contain a hint, "users typically want strong
confidentiality and/or integrity with this service", which mainstream
browsers would honor by default but advanced users could override.  The
point being that a site that sets the hint cannot be blamed if a client
uses the non-TLS service and gets attacked.

I'm not sure if the TLS hint is appropriate for IETF standardization or
would just be a convention among the browsers and sites that have to
cope with user expectations.  But I think it is really what sites want
(at least it's what I want), not HASTLS.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Dec 2010 11:32:56 +0000

Ah, that is much better, sorry.

Architecturally, we have a choice between prefix by port and prefix by
protocol.

I much prefer to have prefix by protocol as ports are a packet layer concept
and TLS is transport layer. We are going to run out of ports very quickly if
we cling to the 'one port per protocol' concept.

I would still prefer to have separate statements for 'this key is valid' and
'must/should use tls'

This should be architected as a generic mechanism for specifying protocol
attributes with the security properties the first set of requirements to be
defined.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Dec 2010 12:28:13 +0000

> stages, how is it combined?

If there is a conflict, the most specific information should take priority,
which will also be the last returned.

So if we have a generic domain-wide property stating 'TLS always offered',
this might be overridden for specific protocols to state 'TLS must be used'
or 'TLS not supported'.

> used for the server ID check?

It really depends on what you are going to do. If it is just turn on TLS on
a http lookup and not mention it to anyone, that is always going to reduce
the sope for the attack. If it is going to be to tell the user 'hey you are
safe, this is definitely PayPal Inc., and slap the logo on the screen, well
we have problems.

If there is a CNAME alias in the discovery chain it is going to have to be
authenticated with an RRSIG if we are going to be able to put any trust in a
key tied to the canonical.

> an assurance and therefore we need something different.  The same is

CNAME does make an assertion that 'this name is equivalent to that name'. If
we respect that, I think we are OK.

> resolver and the DNS server.)

This gets tricky because the RRSIG records start to add up and we end up
needing multi-packet responses if we are not careful.

One way to adress this is to use a DPLS like approach where a DNS request is
always one packet but can lead to a multi-packet response.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Dec 2010 10:15:27 -0500 (EST)

On Tue, 21 Dec 2010, Phillip Hallam-Baker wrote:

> So if we have a generic domain-wide property stating 'TLS always offered', this might be overridden for specific
> protocols to state 'TLS must be used' or 'TLS not supported'. 

That requires more queries though to find out the particular policy if you don't find it at
the host, and after getting a NXDOMAIN you'd have to go look at the domain. Is it worth the
extra query? Especially if we need separate records for the pubkey for each host anyway, it
makes more sense to just bundle the "https preference" in that record.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Dec 2010 16:25:04 +0000

Making it work should always take precedence over an extra DNS round trip.

And arguments attempting to rule out an approach due to performance
considerations should be backed up by actual figures.

It is really very easy to eliminate the DNS round trips and get all the
information required in a single request/response. But that is an
optimization.

It is pretty easy to make something efficient by deciding on one particular
set of circumstances that you are going to support and drive away anyone who
has other ideas from the working group by saying that they are off topic.

The result of that type of behavior is that the protocol stack acquires a
series of special cases that have to be accounted for and worked round in
future designs.

The complete session setup here is going to involve (some) DNS round trips
(some) Digital Signature verifications, a TCP connection setup, a PKI cert
chain construction and verification and a TLS session initiation.

In most cases we can run the network and processing in parallel. I am also
working to design the stack in such a way that the resolver can work
intelligently and pre-fetch as much data as possible. Whether or not we
trust the path that the resolver builds, we want it to be able to do as much
work on our behalf so that all that the endpoint need ever do is verify the
path math.

Since we are about to do a public key exchange protocol, the cost of an
extra DNS round trip is not going to be my primary concern performance wise.
In fact I think you will find that the performance impact is rather minimal
if the code begins fetching the next group of records as it verifies the
signatures on the last ones:

So assuming that we have protocol level detail on http lookup for
www.example.com, the discovery process is going to be:

Phase 1:
   Send requests out for A, AAAA and RR-A records on www.example.com. Since
we do not know whether www.example.com is canonical or wildcarded at this
point, we cannot use prefixes.

Phase 2a:
   As soon as the first response is received, we know if the target domain
is an alias or canonical. We can thus begin the request for the _http._tcp
RR-B and then start verification of the sigs on the first set of records. We
have a minimum of 2.

Phase 3:
   Depending on the relative speed of our machine and our DNS server, we
will receive our protocol specific RR-B result back before or after the
signature verification completes.

On my office setup, the DNS server responds faster, here in the UK, the
Public Key completes first. We really need some timing tests before we
commit to an approach here.

Counter-intuitively, the three step discovery process does not incur any
additional performance penalty over the two step. This is because setting up
a TCP/IP connection is a multi-round trip affair and we can start
constructing the TCP/IP socket as soon as we know the IP address and port.
We do not have to wait to know the protocol options unless there is a reason
to do so.

And all of this is without going a step further and using meta-queries or
DPLS.

I have really not looked into the optimization of the discovery stage in
great detail because I know that it is possible to make browsers using the
full extended protocol discovery mechanism work considerably faster than the
current one.

If we care about performance, lets design a system that allows us to drop in
a geo-location balanced discovery mechanism. Then the browser goes to the
best service automatically.

On Tue, Dec 21, 2010 at 3:15 PM, Paul Wouters <[email-masked]> wrote:

>> this might be overridden for specific

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 21 Dec 2010 11:43:04 -0500

On Tue, 2010-12-21 at 12:28 +0000, Phillip Hallam-Baker wrote:
> On Tue, Dec 21, 2010 at 4:07 AM, Matt McCutchen
> <[email-masked]> wrote:
> It really depends on what you are going to do. If it is just turn on
> TLS on a http lookup and not mention it to anyone, that is always
> going to reduce the sope for the attack. If it is going to be to tell
> the user 'hey you are safe, this is definitely PayPal Inc., and slap
> the logo on the screen, well we have problems.

I'm trying to handle a request for https://example.com, which could have
been manually typed or from a bookmark or another site.  This needs to
have strong semantics for the reasons described at
https://bugzilla.mozilla.org/show_bug.cgi?id=327181#c14 .

> CNAME does make an assertion that 'this name is equivalent to that
> name'. If we respect that, I think we are OK.

/At the DNS level/.  Traditionally, if www.google.com is a CNAME to
www.l.google.com, the reference identifier for the server ID check is
still www.google.com.  We would be changing that and effectively
assuming that the target of the CNAME is trusted to use certificates in
its own name, not just to resolve to the right IP address.  That may be
OK, but it deserves some thought.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Dec 2010 08:57:09 -0800

>You can't. sslstrip made that inheritantly unsafe.

We are talking past each other here. You want to only support one model (the one that cannot be circumvented by sslstrip) and completely prevent users from getting to port 80. I want to let the user choose what they should do, even if it is unsafe, *as long as* they can know securely what the system is hosting.

You believe that users will take your forced approach, and I do not. If you're right, great: they'll be safer. If you're wrong, we have done nothing for them.

>How would a fallback in this case ever be safer?

Please do not put words in my mouth: I never said it would be "safer". However, we have over a decade of experience showing that they want to do it and will ignore anything we put in front of them.

For me, the question is whether we give them better information or not. For you, it is whether we force them to be safe even though they might just turn off the new "feature".

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Dec 2010 09:03:03 -0800

>I'm left to submit a different one.

Indeed. That way, the WG can decide which it prefers. We don't have a WG yet, and we should probably try to get one soon so we can nail down the desired semantics.

>is the possibility of getting attacked.

Quite right.

>uses the non-TLS service and gets attacked.

That type of advice can certainly be added if the WG wants.

>(at least it's what I want), not HASTLS.

It is certainly worth discussing, however, in case we want to add something to the document.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Dec 2010 17:10:52 +0000

> https://bugzilla.mozilla.org/show_bug.cgi?id=327181#c14 .

I would break this down as follows:

1) https is indicated, therefore we have a 'must use TLS' condition.

My current feeling here is that it should not matter how the 'must use'
condition is specified, they all have equal weight. In the past though I did
think that maybe the user typing in https had a stronger weight than
following something from a bookmark.

2) If the lookup is flagged 'MUST use TLS' then we have to have a strong
binding that links the original target domain to the key.

This could be any of the following:

* CA issued certificate under embedded root for example.com (domain can be
canonical or aliased to anywhere, it does not matter)

* CA issued certificate under embedded root for example.net plus a CNAME
with valid RRSIG for example.com -> example.net

* key asserted as valid at example.com with valid RRSIG (domain cannot be
aliased as there is a RR at example.com)

* key asserted as valid at example.net with valid RRSIG plus a CNAME with
valid RRSIG for example.com -> example.net

* path asserted  as valid at example.com with valid RRSIG (domain cannot be
aliased)

* path asserted  as valid at example.net with valid RRSIG plus a CNAME with
valid RRSIG for example.com -> example.net

Now we might want to consider whether we would really want to accept each
one of these cases and if we would want to put in additional considerations
in addition.

If the example given was www.example.com, I would be much happier about
using a certificate for example.com.

And this is looking at the problem only from the perspective of Web lookups.
If there was actual money involved (say we are talking about deep e-commerce
and transactional services) then I would probably have a stronger condition
on the 'valid RRSIG' than merely 'chains to ICANN root'. I would probably
want both trust paths to meet the necessary requirements for the transaction
(which I presume ICANN does not intend to warranty). Although only one path
would actually require insurance.

At some point we would have to think about whether it would be possible to
accept DNSSEC validated RRSIGs in an EV cert chain and if so whether the
ICANN chain would be sufficient or whether that would also require EV
backing.

> OK, but it deserves some thought.

Again we have to work around some of the limitations of the TLS protocol,
one of which is that the target host does not know the domain name until
after the connection has been completed. I know that there is a fix in the
works for this, but it is not fully deployed yet.

We have in the past been considering CNAMEs as merely DNS level plumbing.
Which is of course all you can do when you can't trust the data from DNS.

Once you can trust the data from DNS, things become rather interesting.
Particularly since you now have (potentially) two separate trust chains to
consider.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Dec 2010 09:15:54 -0800

At 11:32 AM +0000 12/21/10, Phillip Hallam-Baker wrote:
>Architecturally, we have a choice between prefix by port and prefix by protocol.

Or "port in the response". I'm not advocating for those, but they have been proposed as well.

--Paul Hoffman, Director
--VPN Consortium

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 21 Dec 2010 12:35:06 -0500

> >is the possibility of getting attacked.

So how is that expressed in HASTLS?  I was proposing "0 443", but you
said that was a lie.  I think this was the only place we disagreed.

-- 
Matt

---

From: James Cloos <[email-masked]>
Date: Tue, 21 Dec 2010 08:58:51 -0500

>>>>> "PH" == Paul Hoffman <[email-masked]> writes:

PH> Just to be clear: are you are proposing DANE adding "bare public key"
PH> *before* any version of TLS allows that?

A bare public key is generally useful, and DANE shouldn't be just about TLS.

-JimC

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Dec 2010 17:50:54 +0000

That is true, we have two dimensions of choice. One is to specify protocols
by prefix or port. The other is to enumerate all the possible choices in one
record or to use a selector approach.

So we could have

1) example.com             XXX "use TLS on port 80"
2) example.com             XXX "use TLS for _http._tcp"
3) _80.example.com         XXX "use TLS"
4) _http._tcp.example.com  XXX "use TLS"
5) example.com             XXX "look at protocol detail"

This has the following consequences:

1 & 2) We have a potential scaling problem if we have a very large site with
a large number of protocols. If we have 1000 Web services at example.com we
would have 1000 XXX records if this is the only option.

3 & 4) Will require 2 round trips to resolve in the general case since if
example.com is a CNAME, the prefix must be applied to the canonical.

5) Introduces some additional complexity to the code, but could perhaps be
tolerated. We only need perform detailed queries if we don't get what we
need in the first lookup.

One odd consequence of DNSSEC is that additional responses no longer get us
out of trouble as we might like. If we have a general record RR-A and a
protocol specific detail record RR-B, a response containing RR-A and likely
relevant RR-B's will now contain two RRSIGs, which will likely bust the
packet length.

Say we have:

example.com             RR-A   path qoweoqwiejoiwqejfo==
example.com             RR-A   detail protocol
_http._tcp.example.com  RR-B   tls required

The response for a query of RR-A on example.com would be:

example.com             RR-A   path qoweoqwiejoiwqejfo==
example.com             RR-A   detail protocol

[Additional]
example.com             RRSIG(RR-A)
_http._tcp.example.com  RR-B   tls required
_http._tcp.example.com  RRSIG(RR-B)

That gets close to the edge size-wise. And is going to get really, really
iffy if we are going to put host specific keys in the mix. We also have a
problem in that the authoritative server has to work out which protocol
records to send as additional RRs. The most requested RRs are not
necessarily the ones where we care about interactive response.

Another option would be to allow enumeration of the most likely to be
requested detail records at the general level:

example.com             RR-A   path qoweoqwiejoiwqejfo==
example.com             RR-A   detail protocol
example.com             RR-A   add [_http._tcp tls required]
_http._tcp.example.com  RR-B   tls required

The response then becomes:

example.com             RR-A   path qoweoqwiejoiwqejfo==
example.com             RR-A   detail protocol
example.com             RR-A   add [_http._tcp tls required]

[Additional]
example.com             RRSIG(RR-a)

Which is likely to serve 99% of cases where a fast response was required.

Ideally, the DNS server is going to simplify administration by automatically
calculating the content of the add records to present.

The hybrid approach allows us the speed of single round trip response for
99% of lookups without introducing scale constraints.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Dec 2010 13:36:44 -0500 (EST)

On Tue, 21 Dec 2010, Phillip Hallam-Baker wrote:

> One odd consequence of DNSSEC is that additional responses no longer get us out of trouble as we might like. If we
> have a general record RR-A and a protocol specific detail record RR-B, a response containing RR-A and likely
> relevant RR-B's will now contain two RRSIGs, which will likely bust the packet length.

This is an argument in favour of merging the HASTLS and TLSA records,
where the TLSA part becomes an optional part inside HASTLS. It would
indeed save us an RRSIG (and an additional roundtrip, if we haven't
optimised it yet)

However, a TLSA record containing a full cert probably already busts
the packet length, regardless of an extra RRSIG or two.

When no CA's are used, a TLSA bare public key or hash would be smaller.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Dec 2010 18:57:04 +0000

Take a look at my proposal in the other thread, I think it meets your
requirements.

If you really really want to put the key into the DNS, then this is how I
would do it:

1) Put the raw key in the DNS
2) Sign with a RRSIG
3) Write a note that states that this combination is directly equivalent to
a PKIX certificate signed under the DNS ZSK with a subjectAltName of the
corresponding domain label.

But this combination would have to be submitted to the TLS working group and
you would probably have to wait until the basic DANE architecture was
defined before that was practical.

On Tue, Dec 21, 2010 at 6:36 PM, Paul Wouters <[email-masked]> wrote:

>  One odd consequence of DNSSEC is that additional responses no longer get
>> us out of trouble as we might like. If we

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 21 Dec 2010 12:39:36 -0700

> Behalf Of Paul Hoffman
> We are talking past each other here. You want to only support one model
> (the one that cannot be circumvented by sslstrip) and completely prevent
> users from getting to port 80. I want to let the user choose what they should
> do, even if it is unsafe, *as long as* they can know securely what the system
> is hosting.
>
> You believe that users will take your forced approach, and I do not. If you're
> right, great: they'll be safer. If you're wrong, we have done nothing for them.

Can you give me a better example here?  If most common web browsers implement this as a "forced" redirect to port-443, users can go in and tweak their internal browser configuration, but I don't expect that most will.  If the sites only does a redirect on port -80 -> 443, the user won't get anything meaningful at port-80 anyway.  So, if they break their port-443 responder, things are totally broken anyway.

I don't imagine many sites deploying identical content on port-80 and port-443, but advertising "must use TLS" to clients, but still supporting unencrypted content on port-80.  I do know of one site doing this, and they are doing it because of problems with filtering gateways in certain countries that want to content-inspect and don't allow HTTPS.  They are forced to still serve all of their content on port-80, even though they are currently sending "Strict-Transport-Security" headers in their HTTPS replies.

I view this as an extreme corner case.  No other site I know of that wants to set STS still wants to serve content on port-80.  

Are you saying that other than the one corner case I've outlined that this will be a common occurrence, and that users will somehow actually want to control this, disregard the policy offered by the site?

- Andy

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 21 Dec 2010 18:25:13 -0500

> A bare public key is generally useful, and DANE shouldn't be just about TLS.

Indeed, the DANE charter puts IPsec in scope, but the current draft is
just about TLS.  (It should probably be renamed to clarify that, unless
the intent is to add IPsec to the same document.)  When we specify DANE
for a security protocol that supports bare public keys, then we can
include bare public keys in the list of association types.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Dec 2010 07:32:59 -0800

>A bare public key is generally useful, and DANE shouldn't be just about TLS.

TLSA *is* just about TLS currently, as was requested by the pre-WG. If you want to change that, that is a completely separate thread.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Dec 2010 07:36:59 -0800

>said that was a lie.  I think this was the only place we disagreed.

HASTLS currently has no semantics for "insecure port does a redirect to strong port" because most applications don't have redirection; only HTTP does. We could add such a semantic if we can find clean wording for it.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Dec 2010 07:43:37 -0800

At 12:39 PM -0700 12/21/10, Steingruebl, Andy wrote:
>Can you give me a better example here?  If most common web browsers implement this as a "forced" redirect to port-443, users can go in and tweak their internal browser configuration, but I don't expect that most will. 

You have no way of knowing that, and I have no way of knowing the opposite. The fact that PayPal has been TLS-only for years has taught PayPal users to expect 443, but PayPal is (sadly) in the very small minority, so your users are not a good metric.

>If the sites only does a redirect on port -80 -> 443, the user won't get anything meaningful at port-80 anyway.  So, if they break their port-443 responder, things are totally broken anyway.

And yet that is exactly the reason we are having this discussion: users have vigorously and willingly said "do this unsafe thing for me" for over a decade.

>I don't imagine many sites deploying identical content on port-80 and port-443, but advertising "must use TLS" to clients, but still supporting unencrypted content on port-80. 

Fully agree, which is why I think Paul Wouters "lie to them" idea will cause confusion to the point of getting people to turn it off.

>I do know of one site doing this, and they are doing it because of problems with filtering gateways in certain countries that want to content-inspect and don't allow HTTPS.  They are forced to still serve all of their content on port-80, even though they are currently sending "Strict-Transport-Security" headers in their HTTPS replies.

It is probably not even "certain countries": there are lots of corporate firewalls that allow this setting.

>I view this as an extreme corner case.  No other site I know of that wants to set STS still wants to serve content on port-80. 

It's *much* too early to tell that: STS is in its infancy, HASTLS isn't even implementable.

>Are you saying that other than the one corner case I've outlined that this will be a common occurrence, and that users will somehow actually want to control this, disregard the policy offered by the…

I certainly am not saying that, and I don't know if Paul Wouters is.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Osterweil, Eric" <[email-masked]>
Date: Wed, 22 Dec 2010 11:46:47 -0800

Hey everyone,

I have a few comments/questions about that draft that I don't _think_ have
yet been covered by the extensive discussion in this thread.  :)

In Section 2.1, should there be any text requiring that the name of a cert
be in bailiwick for the domain name that covers it?  I don't think the text
restricts me from placing a cert under name foo.com and then having that
cert's CN be bar.com.  Shouldn't we try to limit the DNS' ability to verify
certs that are not in bailiwick?

In Section 3.1, I strongly disagree with the comment:
"The preceding paragraph is probably wrong ... There is
   probably no reason to even use this protocol unless you are going to
   fully trust the results..."

IMHO, this doc is not the place to dictate client behavior.  My feeling is
that whether the client fully/partially/doesn't at all trust something
should be their call.  If other working groups that focus on specific
clients feel there are different way to interpret data.  Some of the
discussion so far has threaded around TLS' specification, when to use or not
use PKIX, etc.  Couldn't we be better served by focusing on what the meaning
of data served is, and then allow clients to specify their own behaviors
(with sane suggestions, not mandates)?  I think one of the drawbacks to
specifying behaviors of clients is that we now need to consider their
various requirements.  The extent to which those diverge from each other is
the extent to which I think we might find ourselves straddling diverging
trains.

I don't understand the need for Section 3.1.1.  I would have thought that
this work was ideal for self-signed certs that need orthogonal
authentication mechanisms.  Instead, the text seems to suggest that
self-signed certs are still not to be trusted.  Did I misread this?  If I
generate my own self-signed cert and put it in my zone, then I imagine that
my intent is to rely on DNSSEC validation to vouch for my (say) TLS cert on
my https site, no?

Eric

---

From: "Osterweil, Eric" <[email-masked]>
Date: Wed, 22 Dec 2010 11:46:54 -0800

On 12/19/10 2:35 PM, "Paul Wouters" <[email-masked]> wrote:

>>> But we have no method defined anyway to get all this information at once. So
>>> now this becomes two full roundtrip DNS queries
>> Not at all. If you are about to do TLS and only TLS, then you don't need to
>> query for HASTLS: it is only if you want to do TLS but cannot get there that
>> you need to do HASTLS.
>> 
> And would probably

I don't understand the idea of the use of EDNS0 here?  Op codes in EDNS0
from stub to recursive resolver will not (necessarily) be forwarded to
authoritative name servers during resolution, and OPT records coming back
from authorities are not allowed to be cached, and therefore are not
forwarded to stubs.  Thus, if a client issues a query to anything other than
the authoritative server, it will not be able to use EDNS0, right?  Maybe
I'm missing something?

Eric

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 22 Dec 2010 12:17:53 -0500

On Wed, 2010-12-22 at 07:32 -0800, Paul Hoffman wrote:
> TLSA *is* just about TLS currently, as was requested by the pre-WG. If
> you want to change that, that is a completely separate thread.

Right... so will you rename the draft to a name that contains "tls" so
people do not get confused?

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Dec 2010 10:19:42 -0800

>people do not get confused?

It says TLS right in the title: "Using Secure DNS to Associate Certificates with Domain Names For TLS". Are you suggesting moving "TLS" to earlier in the title? I don't see a good way to do that.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Wed, 22 Dec 2010 14:11:33 -0500 (EST)

> Fully agree, which is why I think Paul Wouters "lie to them" idea will cause confusion to the point of getting people to turn it off.

The matter is not whether or not port 80 has identical content or not. The
issue is that once a client connects on port 80, an attacker can *prevent*
them from going to port 443. I am looking for a DNSSEC validated policy
to tell clients to never connect to port 80.

Once we are on port 443, we will have the TLSA/HASTLS (or CA's) to ensure
we're not ending up at a rogue side

That discussion keeps circling into "you cannot dictate policy" vs
"that's so insecure the protocol should provide a way to prevent it".

And there is also no way to say "we prefer you to come in at port 443",
that would allow the local client policy to overrule a systems preference.

> I certainly am not saying that, and I don't know if Paul Wouters is.

The beviour of first going to port 80 and depending on a redirect to
port 443 is not a corner case. It is the common case. Having a DNSSEC
validatable method to tell the client to start out on port 443 is
needed. Since we are doing TLS related DNS records, this seems a good
time to include support for this.

Again, these attacks are happening, they are not theoretical.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Dec 2010 11:46:38 -0800

>"that's so insecure the protocol should provide a way to prevent it".

We agree that we keep circling to an either X or Y question. I would state the question as "you { can | cannot } dictate a policy that demands that a client only use a secure service on a particular host". Once we have agreement on whether that is "can" or "cannot", moving forwards on the resulting protocol is much easier.

>that would allow the local client policy to overrule a systems preference.

We could add such a preference to the announcement protocol, but seems kind of silly: it is obvious that servers would prefer you use the secure protocol.

>port 443 is not a corner case. It is the common case.

Fully agree.

>Having a DNSSEC
>needed.

Disagree, but no need to bludgeon that.

>Since we are doing TLS related DNS records, this seems a good

Fully agree.

>Again, these attacks are happening, they are not theoretical.

No one has said otherwise.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Dec 2010 21:39:51 +0000

I look at the problem differently.

The server site is merely describing its local security policy to whoever
might want to connect. So it is making statements such as

"TLS is always offered"
"TLS must be used"
"IPSEC must be used"
"A path for the cert can be formed from CA cert X"
"The key is Y"

These are all merely descriptive of the server security policy. IOf clients
want to connect, they can make their own choices.

Server policies such as 'must use TLS' are going to be very hard to
implement outside of closed environments. The NSA and banks can use that
policy internally. It would be rather difficult for most sites to do so.

The implicit policy approach that people have been pushing is not going to
work very well in practice because there is a wide range of possible
security policies sites will want to implement and the implicit approach
invites everyone to read into the spec whatever they would like to see
there.

If the implicit approach is followed, we will have a long series of
arguments of this type and at the end each browser will interpret the
implicit semantics as makes sense to them.

We will do much better with a clean architecture that separates the
assertion of keys, paths and other credentials from the declaration of
security policy.

It is convenient to do both in a single record. Doing so goes beyond the
scope of the CERT record, but I don't see much value in using that anyway.

On Wed, Dec 22, 2010 at 7:46 PM, Paul Hoffman <[email-masked]> wrote:

> We agree that we keep circling to an either X or Y question. I would state
> the question as "you { can | cannot } dictate a policy that demands that a
> client only use a secure service on a particular host". Once we have
> agreement on whether that is "can" or "cannot", moving forwards on the
> resulting protocol is much easier.
>
> We could add such a preference to the announcement protocol, but seems kind
> of silly: it is obvious that servers would prefer you use the secure
> protocol.
>
> >>>Are you saying that other than the one corner case I've outlined that
> this will be a common occurrence, and that users will somehow actually want
> to control this, disregard the policy offered by the site?
> >>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Dec 2010 21:42:32 +0000

Actually, that was what you requested in the Pre-WG.

Moreover at the time you kept saying that these are all decisions that the
WG can revisit should it be formed.

And I predicted at the time that this tactic would be used.

On Wed, Dec 22, 2010 at 3:32 PM, Paul Hoffman <[email-masked]> wrote:

> TLSA *is* just about TLS currently, as was requested by the pre-WG. If you
> want to change that, that is a completely separate thread.
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Wed, 22 Dec 2010 14:59:13 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker

> These are all merely descriptive of the server security policy. IOf clients want to connect, they can make their own choices.

They can, of course.  We can't "enforce" it on them, as we don't directly control their code.  But, what we can control is whether this is a  "MAY" or a "MUST" requirement in the spec.  In my mind it's a MUST, not a MAY/SHOULD.  We don't want fuzziness here, as we're trying to protect against known attacks and we want uniformity of implementation.  My sense from the major browser vendors - who really are the major target for this spec anyway from the client side - is that they'd want MUST also, and uniformity.

I also think it should be explicit, not implicit in publishing keys in DNS. I would deploy it today if I could, totally absent a fully specified keys-in-dns spec from this group.

- Andy

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Dec 2010 14:07:58 -0800

At 9:42 PM +0000 12/22/10, Phillip Hallam-Baker wrote:
>Moreover at the time you kept saying that these are all decisions that the WG can revisit should it be formed.

Exactly right.

>And I predicted at the time that this tactic would be used.

"This tactic"? What problem do you have with requesting that an issue be opened in the WG? That's the way the IETF works. If you don't like that, maybe you can find another SDO that works more to your liking.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Dec 2010 22:26:18 +0000

Well since you appeared to be telling someone 'this has already been
decided, shut up and go away', the fact that earlier you were telling people
that this would be discussed later is rather relevant.

Since you clearly had no intention of implying that this issue had already
been decided, we can now have the discussion we agreed earlier to postpone,
having made no decision or commitment whatsoever.

On Wed, Dec 22, 2010 at 10:07 PM, Paul Hoffman <[email-masked]>wrote:

> "This tactic"? What problem do you have with requesting that an issue be
> opened in the WG? That's the way the IETF works. If you don't like that,
> maybe you can find another SDO that works more to your liking.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Dec 2010 23:05:10 +0000

The part that worries me is attempting to define the semantics of the
security policy statement in terms of the client behavior.

Thinking in terms of the desired endpoint behavior is easy for people, but
rather hard for machines. If this scheme is going to be manageable on a
large scale, we need to be able to automate the generation of the security
policy information. That is going to be easiest if the security policy maps
directly to the server state rather than some desired client state.

Now clearly, if client is reading the security policy it MUST NOT attempt or
accept a connection that is incompatible with that stated policy and SHOULD
always attempt to make the strongest connection possible that is compatible
within the intersection of their security policies.

But working in terms of the client behavior is unhelpful because a sensible
client is always going to ensure the connection is secure.

For example, consider the following servers:

Server A: Requires use of TLS

Server B: Always offers TLS

Off hand I can't think of a reason why an endpoint client I wrote would
differentiate between those two cases. I am going to always attempt to
connect using TLS and never bother with trying the http connection.

There is an important difference: Attempting to connect to Server A enclair
can only be the result of either a mis-stated security policy or a downgrade
attack.

On Wed, Dec 22, 2010 at 9:59 PM, Steingruebl, Andy <
[email-masked]> wrote:

> Behalf Of Phillip Hallam-Baker
>
>
> > These are all merely descriptive of the server security policy. IOf
> clients want to connect, they can make their own choices.
>
> They can, of course.  We can't "enforce" it on them, as we don't directly
> control their code.  But, what we can control is whether this is a  "MAY" or
> a "MUST" requirement in the spec.  In my mind it's a MUST, not a MAY/SHOULD.
>  We don't want fuzziness here, as we're trying to protect against known
> attacks and we want uniformity of implementation.  My sense from the major
> browser vendors - who really are the major target for this spec anyway from
> the client side - is that they'd want MUST also, and uniformity.
>
> I also think it should be explicit, not implicit in publishing keys in DNS.
> I would deploy it today if I could, totally absent a fully specified
> keys-in-dns spec from this group.
>
> - Andy
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Dec 2010 15:16:23 -0800

At 10:26 PM +0000 12/22/10, Phillip Hallam-Baker wrote:
>Well since you appeared to be telling someone 'this has already been decided, shut up and go away', the fact that earlier you were telling people that this would be discussed later is rather relevant.

I explicitly said "If you want to change that, that is a completely separate thread." What part of the word "If" did you not understand?

>Since you clearly had no intention of implying that this issue had already been decided, we can now have the discussion we agreed earlier to postpone, having made no decision or commitment whatsoever.

Correct.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Dec 2010 23:30:13 +0000

No, what you actually said was

"TLSA *is* just about TLS currently, as was requested by the pre-WG. If you
want to change that, that is a completely separate thread."

The terms 'requested' and 'change' imply a status quo.

We do not have a status quo for the simple reason that you stepped in to
suppress discussions that might have led to one being formed by saying that
they should take place after the WG was formed.

If people wondered why I took exception to earlier attempts to defer other
discussions, they will now see the explanation.

On Wed, Dec 22, 2010 at 11:16 PM, Paul Hoffman <[email-masked]>wrote:

> I explicitly said "If you want to change that, that is a completely
> separate thread." What part of the word "If" did you not understand?
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Dec 2010 15:45:21 -0800

At 11:30 PM +0000 12/22/10, Phillip Hallam-Baker wrote:
>"TLSA *is* just about TLS currently, as was requested by the pre-WG. If you want to change that, that is a completely separate thread."
>
>

Correct.

>We do not have a status quo for the simple reason that you stepped in to suppress discussions that might have led to one being formed by saying that they should take place after the WG was formed.

Phill, given that you have been a WG chair, you must know that what you are saying is poppycock. A WG starts somewhere. Even your WG did, as the archives clearly show.

In this case, it starts with the document authors guessing on what would be accepted by the WG and asking for people to have a discussion. If Jakob and I guessed wrong, we'll be corrected by the WG.

>If people wondered why I took exception to earlier attempts to defer other discussions, they will now see the explanation.

Where?

--Paul Hoffman, Director
--VPN Consortium

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 23 Dec 2010 01:54:44 +0200

> want to connect, they can make their own choices.

I don't consider the first and last two as not policy but as facts. The other
two are policy. 

I consider statements about behaviour of genuine server(s) and domain as whole
as facts. These include if it offers (START)TLS or not, what keys it uses, what
CAs (if any) those certificates chain to, etc... Those three statements all
directly map to properties of the host.

"TLS/IPSEC must be used" don't directly map to any property of the server nor
the domain.

> policy internally. It would be rather difficult for most sites to do so.

That's because they are policy.

-Ilari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Dec 2010 10:14:04 +0000

On Wed, Dec 22, 2010 at 11:45 PM, Paul Hoffman <[email-masked]>wrote:

> >"TLSA *is* just about TLS currently, as was requested by the pre-WG. If
> you want to change that, that is a completely separate thread."
> >
> >
> Phill, given that you have been a WG chair, you must know that what you are
> saying is poppycock. A WG starts somewhere. Even your WG did, as the
> archives clearly show.
>

Please try to keep your language under control. And its a good idea to
understand what a word actually means before you use it. 'Poppycock' means
soft feces.

A working group does start somewhere. But as you admit, this point was
raised earlier and at your personal insistence deferred to a later time.

When others agreed to defer the discussion it was on the implicit
understanding that no decision had been taken, not as you are now attempting
to claim that your personal preference had been adopted as WG policy in the
interim.

You keep taking great exception when people allegedly put words into your
mouth but have no compunction about speaking for the whole Working Group to
put words in our mouths.

And as for being a WG chair, I note that on several occasions in this thread
you have either stated or implied that your way is the consensus and that if
others don't like that choice they can form their own group. I regard that
approach to be an attempt to bully people into agreeing with you. Which is
not something I would have tolerated as a WG chair.

I suggest that from now on we argue technical issues strictly on the merits
and that you stop trying to suppress discussion by first claiming that it is
too early to raise an issue and afterwards that it is now too late.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Dec 2010 10:20:15 +0000

On Wed, Dec 22, 2010 at 11:54 PM, Ilari Liusvaara <
[email-masked]> wrote:

> clients
> two are policy

Well they are certainly objective statements of fact about the server
security policy.

Which is the point. Security policy can be a very nebulous concept. But if
we stick to objective statements of fact we can avoid getting stuck.

Why do you think the last two are not factual? Could we express them in a
fashion that you consider to be objective?

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 23 Dec 2010 16:15:05 +0200

> fashion that you consider to be objective?

I said last two ARE factual (might have miscommunicated this).

-Ilari

---

From: Ben Laurie <[email-masked]>
Date: Thu, 23 Dec 2010 14:35:09 +0000

> You have no way of knowing that, and I have no way of knowing the opposite. The fact that PayPal has been TLS-only for years has taught PayPal users to expect 443, but PayPal is (sadly) in the very…

Note that there are various institutions that view TLS as an evil not
to be tolerated (schools being a notable example), so many services
are unable to go TLS-only.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 23 Dec 2010 14:43:36 +0000

> "TLS/IPSEC must be used" don't directly map to any property of the server nor

If you express them as "Only TLS/IPSEC are offered", then they, too,
become factual.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 23 Dec 2010 06:43:44 -0800

> are unable to go TLS-only.

In fact, this is why HTTPS://www.google.com redirects to https://encrypted.google.com

OTOH, we shouldn't encourage this behavior in DNS or elsewhere:  If network policy demands unencrypted traffic, it should instead demand that the browsers snitch the session keys to the IDS (easy enough to do) and the IDS blocks unsnitched sessions only.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Dec 2010 17:02:24 +0000

There is also a fairly important Wall Street use case.

Regulators require banks to have complete archives of client-broker
communications. So brokers connecting up to TLS protected Web sites from
work machines becomes problematic. So some block TLS entirely.

I prefer a solution where the browser knows that the security policy for the
zone requires the TLS connection to be intermediated *AND* clearly notifies
the user that this is in use.

Obviously, there are very big problems with this type of behavior when it is
being used by ISPs to spy on their customers, as certain authoritarian
governments require. But those are not use cases I think we need to either
support or attempt to prevent.

On Thu, Dec 23, 2010 at 2:35 PM, Ben Laurie <[email-masked]> wrote:

> > You have no way of knowing that, and I have no way of knowing the
> opposite. The fact that PayPal has been TLS-only for years has taught PayPal
> users to expect 443, but PayPal is (sadly) in the very small minority, so
> your users are not a good metric.
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Dec 2010 16:12:11 -0500 (EST)

On Thu, 23 Dec 2010, Phillip Hallam-Baker wrote:

[ MITM SSL, authorised or not]

> Obviously, there are very big problems with this type of behavior when it is being used by ISPs to spy on their
> customers, as certain authoritarian governments require. But those are not use cases I think we need to either support

Agreed.

> or attempt to prevent. 

Disagreed. Not just by me, but as clearly stated in RFC 1984

 	The IAB and IESG would like to encourage policies that allow ready
 	access to uniform strong cryptographic technology for all Internet
 	users in all countries.

[...]

 	Cryptography is the most powerful single tool that users
 	can use to secure the Internet. Knowingly making that tool weaker
 	threatens their ability to do so, and has no proven benefit.

But I think we agree that a big large warning in the browser about the DNSEEC/CA validated key mismatch
is where our preventative action should stop.

> are unable to go TLS-only.

I remember France once tried to ban ssh nationally as well. Which ones
would we be willing to support and which ones would we not? I think RFC
1984 is clear that at the protocol level, we should not make decisions
based on the crypto restrictions of certain regimes or businesses,
and that any crippling of crypto should be left to implementors.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Dec 2010 21:34:26 +0000

I was referring there to DANE rather than the IETF.

In my view we should separate design of censorship busting protocols from
design of regular protocols.

If you are going to deploy something that is robust you have to make busting
censorship your first last and only goal (e.g. Tor).

One of the un-noticed costs of the cryptowars was that making protocols
resistant to Louis Freeh became a higher priority than making them easy to
use. And as a result we ended up with two email encryption schemes that are
really, really secure but practically unused.

A protocol should be one or the other, trying to be both ends up with a
scheme that serves neither purpose.

This particular capability is like key-escrow. It is something that is
perfectly acceptable within specific circumstances but totally unacceptable
when it becomes a mandate with the government in control.

On Thu, Dec 23, 2010 at 9:12 PM, Paul Wouters <[email-masked]> wrote:

>> customers, as certain authoritarian governments require. But those are not
>> use cases I think we need to either support
>>
>
> Agreed.
>
>  or attempt to prevent.
>>
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Dec 2010 16:42:11 -0500 (EST)

> I was referring there to DANE rather than the IETF.

But DANE is part of an IETF WG, and RFC1984 is a firm statement by the IAB/IESG

> In my view we should separate design of censorship busting protocols from design of regular protocols. 

You mentioned MITM's should not be "either supported or attempted to prevent".

I wanted to remind everyone that the IETF concensus is that preventing
MITM is very much its goal (on the protocol level)

> If you are going to deploy something that is robust you have to make busting censorship your first last and only goal
> (e.g. Tor).

Agreed, but for MITM attacks against TLS/SSL, we should clearly have a "MUST abort" when the
client detects a MITM for our protocol specifications. And not build in a "china" or "school" or
"stock brokers" function. Leave that to the implementors (as RFC1984 states)

> One of the un-noticed costs of the cryptowars was that making protocols resistant to Louis Freeh became a higher
> priority than making them easy to use. And as a result we ended up with two email encryption schemes that are really,
> really secure but practically unused. 
> 
> A protocol should be one or the other, trying to be both ends up with a scheme that serves neither purpose.

I'm not sure if I agree, but regardless this seems out of scope on the current discussion on
"client policy" vs "protocol specification placed limits on what clients SHOULD do".

> This particular capability is like key-escrow. It is something that is perfectly acceptable within specific
> circumstances but totally unacceptable when it becomes a mandate with the government in control.

And hence, again, RFC1984 says "do not add escrow to the protocol, add it to the implementation".

Which is what I am arguing for the "MUST NOT fallback to port 80"

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Dec 2010 21:51:58 +0000

Well it was 14 years ago.

It was an informational RFC and is not binding on the current membership:

Status of This Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited

Moreover it does not make the statement you allege concerning MITM.

So not only is RFC 1984 not binding IETF policy, it does not make the
statement you claim.

I do wish that people would actually read documents that they keep
referencing. In this case it is only 4 pages long.

On Thu, Dec 23, 2010 at 9:42 PM, Paul Wouters <[email-masked]> wrote:

>  If you are going to deploy something that is robust you have to make
>> busting censorship your first last and only goal
>> (e.g. Tor).
>>
>
>> resistant to Louis Freeh became a higher
>> priority than making them easy to use. And as a result we ended up with
>> two email encryption schemes that are really,
>> perfectly acceptable within specific

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Dec 2010 20:57:45 -0500 (EST)

> Well it was 14 years ago.

I don't see an "obsoleted by RFCxxxx"?

> It was an informational RFC and is not binding on the current membership:

Yes, an information RFC not just by any WG, but by the IAB and the IESG.
that might suggest it is kinda a big deal.

> Moreover it does not make the statement you allege concerning MITM.

I will quote again:

Just to make it more clear, to me allowing a port 80 downgrade falls
under "making cryptography [...] weaker".

> So not only is RFC 1984 not binding IETF policy, it does not make the

I hope I sufficiently addressed this above. If not, please let me know.

> referencing. In this case it is only 4 pages long. 

I read them, and I still strongly disagree with your statement. But I will
refrain from claiming you did not read the RFC, because I have no way of
proving any such hypothesis. Perhaps you should give me the same courtesy.

And stating you wish to protect the stock brokers from only using https
(for regularory compliance) while claiming the common user being vulnerable
to port 80 downgrade is out of scope is something I strongly disagree with
and frown upon.

>       In my view we should separate design of censorship
>       busting protocols from design of regular protocols. 
> 
> 
>       If you are going to deploy something that is robust you
>       have to make busting censorship your first last and
>       only goal
>       (e.g. Tor).
> 
> 
>       One of the un-noticed costs of the cryptowars was that
>       making protocols resistant to Louis Freeh became a
>       higher
>       priority than making them easy to use. And as a result
>       we ended up with two email encryption schemes that are
>       really,
>       A protocol should be one or the other, trying to be
>       both ends up with a scheme that serves neither purpose.
> 
> 
>       This particular capability is like key-escrow. It is
>       something that is perfectly acceptable within specific
>       circumstances but totally unacceptable when it becomes
>       a mandate with the government in control.
> 
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 24 Dec 2010 07:48:46 +0200

> - Since hash #0 is identity anyway, is there reason not to merge 1 and 2

Actually, I think the whole "certificate type" is underspecified.

The following is how I would modify it:

- Merge 1 and 2. Hash type will tell full certificates and certificate
  hashes apart anyway. This removes the possiblity of "01 00" and "02 02"
  nonsense.
- Merge 3 and 4. Same reasons as for previous.
- Specify that unknown certificate types are to be treated as usable but
  not matching if the hash function is known.

The reson for last one is that were new certificate type (raw keys?) to
be added to TLS, otherwise one would need a new DNS RR and interaction
between that type and TLSA would have to be specified (plus other muti-
RR issues!). The result might even be a security issue if client not
supporting new RR tries to connect to server using new certificate type
only (the connection should fail and not offer some attacker oppurtunity
to send a mistakenly issued PKIX certificate).

The last attack would not be possible if unknown records were usable but
not matching. The client would see only type 5 (or whatever) records and
conclude (correctly) that connecting can't possibly work, even if the
connection is MITM'd by someone with mistakenly issued PKIX certificate
for the server.

-Ilari

---

From: Ben Laurie <[email-masked]>
Date: Fri, 24 Dec 2010 11:03:59 +0000

+1

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Dec 2010 12:07:31 +0000

Again you completely misrepresent me and those you are quoting.

There is a huge difference between not supporting the key escrow schemes
demanded by Louis Freeh and making resistance to government mandated
intercept the primary design consideration.

My point is that you do not achieve security through application of a
blinkered ideology. There are many cases where one security interest is
trumped by another.

In the case of Wall Street traders there is a confidentiality concern, but
the concern is the responsibility of the firm and NOT the individual trader.
Not only does a broker not have a right to engage in private conversations
with the company clients, enforcing such a rule is in the interests of both
the customer and the company.

Hey, if someone is prepared to pay me a million bucks a year to gamble with
a billion dollars or so of their money, they can read my email too. OK,
maybe a bit more than a million, but if they will throw in an Aston I could
be tempted.

In any case, the question is moot since local policy will always trump the
standard. If the local policy is that all traffic must be en-clair at the
firewall, the person who writes that code is going to ignore what the spec
says.

Trying to design out the possibility of people doing this type of thing is
pointless. We tried that in the cryptowars and ended up with junk protocols
nobody uses.

Just design stuff that works when people are not mucking with the
infrastructure and then consider how to fix the infrastructure level attack
as a completely separate issue.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 26 Dec 2010 16:04:06 -0800

Greetings again. I still don't like the idea of a host asserting a client policy preference, but I hear many folks wanting it. I think I have added it cleanly in draft-hoffman-server-has-tls-02, but I'm not sure and would like to hear more from folks, especially those who like the current semantics in draft-hodges-strict-transport-sec. The new draft is at <http://tools.ietf.org/html/draft-hoffman-server-has-tls-02>, and the diffs from the last draft are at <http://tools.ietf.org/rfcdiff?url2=draft-hoffman-server-has-tls-02.txt>.

FWIW, I don't think that draft-hoffman-server-has-tls formally belongs in either DANE or WEBSEC, and will probably try to move it into the AppsArea WG in the new year, but if folks want to comment before then, that's great.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 Dec 2010 22:16:20 -0500 (EST)

> Greetings again. I still don't like the idea of a host asserting a client policy preference, but I hear many folks wanting it. I think I have added it cleanly in draft-hoffman-server-has-tls-02, bu…

I'm not sure if CIO/CSO/CFB are still described properly, because it is
no longer a "client type" but it depends on the particular tripplet.

For instance, if we have IN HASTLS (25 25 0 80 443 1) then what would you
call the "server" or the matching "client"? They are CFB/SFB for some protocols
and CSO/SSO for other protocols.

 	1 -- If the client could be configured as either CFB or CSO, and
 	the host's administrator was able to configure the client, that
 	administrator would configure the client as CSO. Stated another
 	way, the host's administrator does not want any CFB client to
 	access the host.

This should probably have some "protocol" modifiers added, eg

 	1 -- If the client could be configured as either CFB or CSO for a
         particular service tripplet, and ..."

Perhaps it should also be stated that the client policy preference MUST be
0 if either the secure or insecure port is specified as 0.

Other then that, the changes address all my issues. Thanks!

Paul

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 27 Dec 2010 16:52:34 -0700

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Hoffman
> 
> Greetings again. I still don't like the idea of a host asserting a client policy
> preference, but I hear many folks wanting it. I think I have added it cleanly in
> draft-hoffman-server-has-tls-02, but I'm not sure and would like to hear
> more from folks, especially those who like the current semantics in draft-
> hodges-strict-transport-sec. The new draft is at
> <http://tools.ietf.org/html/draft-hoffman-server-has-tls-02>, and the diffs
> from the last draft are at <http://tools.ietf.org/rfcdiff?url2=draft-hoffman-
> server-has-tls-02.txt>.

A few thoughts.

1. I think it would be useful in the security considerations to discuss (briefly?) the MITM threat model at play here.  You discuss it in the context of delivery of the DNS data itself, but not the motivation for this proposal in the first place.  A major motivation is the MITM attack against the non-TLS version of a protocol.

2. Do you have any examples of CFB apps?  A few clients such as Mozilla's Thunderbird when in "discovery" mode will try this, but it isn't very common in my experience, and it would be good to have a few examples I could think about.

3. We argues a lot when working on HSTS about the proper behavior of a server supporting HSTS and whether it SHOULD or MUST redirect all HTTP traffic to HTTPS.  You come down on the MUST front in this proposal, at least philosophically. Some sites (well, 1 anyway) have chosen not to. I won't go into the details, and it isn't a major issue.

4. One way in protocols that don't support redirects to also indicate to a client that it should not communicate "insecurely" is with error codes.  POP/IMAP can both do this with error codes, some of which are usually shown to the user (in some implementations).  So, though they don't support protocol-level "redirects" like HTTPS, then still allow signaling to the client albeit in a non-automated way.

5. Maybe this came up earlier but I'm still slightly confused on overall semantics of this proposal.  If HASTLS is about TLS, it is odd to me that it should talk about non-TLS policy, where it listens "insecurely", etc.  I have a few thoughts on the general topic of service discovery, but HASTLS seems to bundle two ideas together: a) service discovery and b) whether/how that service operates with TLS.  It seems to me that they are slighty different, and co-mingling them doesn't seem quite right.   

Related to #5, the biggest protocol in our minds that is problematic wrt sslstrip-type attacks is HTTP/HTTPS, because it is the one protocol that where non fully qualified names, URI(L?)'s are entered, and where the browser has some of its own converting between names and protocols that go on.  It  is also the one protocol most easily MITM'd in a lot of ways, because much of the web is HTTP, and active attackers can easily insert references to resources causing the client to retrieve them.  The same isn't true of most other protocols such as IMAP.  Which isn't to say that this proposal isn't a good idea for IMAP, its just that IMAP/POP aren't quite so ripe for abuse generally.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 27 Dec 2010 21:35:02 -0500 (EST)

> 5. Maybe this came up earlier but I'm still slightly confused on overall semantics of this proposal.  If HASTLS is about TLS, it is odd to me that it should talk about non-TLS policy, where it list…

You are somewhat right.

For services where you have no secure/TLS version, their entries could
simply be omitted and not be part of the HASTLS record.  That is, you
could not specify:

 	insecure.org. IN HASTLS (80 0 0 25 25 1)

but instead:

 	insecure.org. IN HASTLS (25 25 1)

An exception might be if you want to prevent clients from connecting to
you at all, by specifying

 	insecure.org. IN HASTLS ()

Though I blieve the HASTLS record should not become the "legitimate
open port list" of a host though, people should not trust clients to
adhere to HASTLS for their server security, and instead have proper
firewall policies.

Though I think Paul Hoffman would prefer the first entry over the second
one. Though all records, including not having a HASTLS record at all,
should have the same effect for clients supporting this RRTYPE. Though
they could decided there is nothing on port 80 and refuse to even try
in the latter two examples.

Personally, I would prefer not to have to build a list of insecure ports
if I have no secure version of it available, but then again I would
expect any client that can do HASTLS to be able to do the secure version
anyway. And for new protocols to not come out with an insecure version.

Perhaps it makes sense to rename HASTLS to something else. TLSSTAT? STATTLS? TLSAVAIL?

Paul

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 28 Dec 2010 09:25:22 -0700

> Though I blieve the HASTLS record should not become the "legitimate open
> port list" of a host though, people should not trust clients to adhere to
> HASTLS for their server security, and instead have proper firewall policies.
> 
> Personally, I would prefer not to have to build a list of insecure ports if I have
> no secure version of it available, but then again I would expect any client that
> can do HASTLS to be able to do the secure version anyway. And for new
> protocols to not come out with an insecure version.
> 

The idea I've been toying around with is actually changing how service lookups happen.  I don't have a well-formulated idea yet but it seems that just as many protocols/applications (I struggle for the right word here) do SRV lookups, maybe we ought to somehow bundle the TLS preference into that lookup scheme.   If we did, we could tackle the keys-in-dns problem and has/requires-TLS problem in the same SRV lookup.  HASTLS would be a part of looking up the properties of a service you're about to connect to.

I'm more than a little inexperienced with existing SRV lookups, so can't quite articulate how I think this would best work.

- Andy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Dec 2010 17:04:32 +0000

I think that is a great idea.

SRV and extended discovery in general can deliver advantages in addition to
security.

I have found persuading people to change protocol behavior for the sake of
security alone to be very hard. SRV offers potential reliability and
performance benefits. Which makes it much easier to get adoption.

On Tue, Dec 28, 2010 at 4:25 PM, Steingruebl, Andy <
[email-masked]> wrote:

> if I have
> The idea I've been toying around with is actually changing how service
> lookups happen.  I don't have a well-formulated idea yet but it seems that
> just as many protocols/applications (I struggle for the right word here) do
> SRV lookups, maybe we ought to somehow bundle the TLS preference into that
> lookup scheme.   If we did, we could tackle the keys-in-dns problem and
> has/requires-TLS problem in the same SRV lookup.  HASTLS would be a part of
> looking up the properties of a service you're about to connect to.
>
> I'm more than a little inexperienced with existing SRV lookups, so can't
> quite articulate how I think this would best work.
>
> - Andy

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Dec 2010 16:55:16 -0800

Good call, yes.
> 2. Do you have any examples of CFB apps?
Many. Most SMTP servers, for example. Many POP and IMAP clients. Many 
SIP clients. And so on.
> A few clients such as Mozilla's Thunderbird when in "discovery" mode will try this, but it isn't very common in my experience, and it would be good to have a few examples I could think about.
You are focusing on "current web", not "TLS".
> 3. We argues a lot when working on HSTS about the proper behavior of a server supporting HSTS and whether it SHOULD or MUST redirect all HTTP traffic to HTTPS.  You come down on the MUST front in this proposal, at least philosophically.
If I did, it was a mistake. I don't see where I do so.
> Some sites (well, 1 anyway) have chosen not to. I won't go into the details, and it isn't a major issue.
I think both policies are reasonable.
> 4. One way in protocols that don't support redirects to also indicate to a client that it should not communicate "insecurely" is with error codes.  POP/IMAP can both do this with error codes, some…
The POP and IMAP error codes are too obtuse to show to end users.
> 5. Maybe this came up earlier but I'm still slightly confused on overall semantics of this proposal.  If HASTLS is about TLS, it is odd to me that it should talk about non-TLS policy, where it listens "insecurely", etc.
Any client-server protocol that does not require TLS all the time will 
have instances where the server is insecure. Some clients will want to 
know if a server is even offering the non-TLS version; if not, it will 
never try to go to the non-secure port on that server.
> I have a few thoughts on the general topic of service discovery, but HASTLS seems to bundle two ideas together: a) service discovery and b) whether/how that service operates with TLS.  It seems to me that they are slighty different, and co-mingling them doesn't seem quite right.
HASTLS is *not* about service discovery at all. The spec states "Setting 
both the "insecure-port" and "secure-port" to 0 in a porttriple is 
explicitly undefined", but that maybe should be strengthened to a 
prohibition.
> Related to #5, the biggest protocol in our minds that is problematic wrt sslstrip-type attacks is HTTP/HTTPS, because it is the one protocol that where non fully qualified names, URI(L?)'s are ente…
I understand your emphasis on TLS, but there is a much bigger world out 
there, and attacks in that world are just as serious. If one security 
extension can cover multiple server protocols, that would be good, I think.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Dec 2010 16:55:27 -0800

>     insecure.org. IN HASTLS (25 25 1)
This does not tell an HTTP client that is CIO or CFB that there is, in 
fact, a server at port 80. Why do you want to prevent them from knowing 
that?
>     insecure.org. IN HASTLS ()
That is prohibited by the spec, on purpose.
Correct.
> in the latter two examples.
Yes, that's a reasonable policy.
> anyway. And for new protocols to not come out with an insecure version.
Both those expectations are probably unwise. The first assumes that all 
clients that use HASTLS want to do TLS; some won't. The second assumes 
that all applications will use TLS for security, which is probably unwise.
> Perhaps it makes sense to rename HASTLS to something else. TLSSTAT? 
Bikeshed.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Dec 2010 16:55:34 -0800

> no longer a "client type" but it depends on the particular tripplet.
The client still gets to decide what its policy is. It gets to decide 
whether or not it conforms to the HASTLS semantics.
> call the "server" or the matching "client"?
I don't understand the question. There is an SMTP server and an HTTP 
server. The system requesting the information might have clients for 
both, either, or none.
> They are CFB/SFB for some protocols
IN the above, if there is an SMTP client, it could be either CSO, CFB, 
or CIO.
>         particular service tripplet, and ..."
Good point, yes. I'll add that in the next draft.
> 0 if either the secure or insecure port is specified as 0.
I don't think so. This can lead to some silly states, like if you 
specify "1" and the TLS-based service goes down for some reason. I said 
in the sentence following what you quoted above:
    Note that specifying 1 for the client policy preference when a host
    does not support a protocol securely makes no sense, but it also does
    no harm.
I still believe that is true.
> Other then that, the changes address all my issues. Thanks!
Glad to hear it.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 28 Dec 2010 21:16:52 -0500 (EST)

On Tue, 28 Dec 2010, Paul Hoffman wrote:

> The client still gets to decide what its policy is. It gets to decide whether 
> or not it conforms to the HASTLS semantics.

I meant (as below) that a client type now belongs to a service tripplet.

> I don't understand the question.

Same here

> IN the above, if there is an SMTP client, it could be either CSO, CFB, or 
> CIO.

I meant to talk about servers in this aspect, because based on the HASTLS record
we know what the server is. And they can be CFB for some and SFB for others,
depending on service tripplet.

> I don't think so. This can lead to some silly states, like if you specify "1" 
> and the TLS-based service goes down for some reason.

If either the insecure or the secure service is 0 (but not both), it means
HASTLS compliant clients will only have one way to connect. So there is no
"preference". You can only connect to the one secure or insecure port.

> I said in the sentence  following what you quoted above:

But it does no good either. In some sense, it is "lying" because there can be
no preference. Imagine an implementation first checks the 5th byte, and then
blindly assumes there is a secure and insecure version (why else list the
preference as 1) and then picking the secure version, while the HASTLS record
stated (80 0 1) and there is none.

I would still say, preference SHOULD or MUST be 0 if the service is only offered
with one method.

>> Other then that, the changes address all my issues. Thanks!

Thanks for your work on this!

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Dec 2010 00:26:49 -0500 (EST)

Actually, one more question. You wrote in section 2:

 	An example of a hash for a single certificate:

 	www.example.com. IN TLSA 1 2 AgHne3GdTpxjwLCgMzvgpBiOSQthjg==

The hash type here is 2, and you refer to http://www.iana.org/assignments/tls-parameters
which refers to http://tools.ietf.org/html/rfc5246 for sha1, but I did not find that RFC
(about TLS) mentioning anything about encoding of the hash.

The above listed encoding seems to not have enough characters to be a base64
string of a sha1 hash, so I'm a little confused what you generated. Which
means it should probably get a better explanation in the text.

Paul

---

From: Ben Laurie <[email-masked]>
Date: Wed, 29 Dec 2010 13:32:51 +0000

On 29 December 2010 05:26, Paul Wouters <[email-masked]> wrote:
> The hash type here is 2, and you refer to
> http://www.iana.org/assignments/tls-parameters
> string of a sha1 hash,

It is 30 characters, + 2 padding, which seems just about right to me.

> so I'm a little confused what you generated. Which

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 29 Dec 2010 22:11:31 +0200

> Both those expectations are probably unwise. The first assumes that
> all clients that use HASTLS want to do TLS; some won't. The second
> assumes that all applications will use TLS for security, which is
> probably unwise.

Have field for security protocol type. And I think TLS should split into
TLS (start connection with TLS client hello) and STARTTLS (upgrade to
TLS).

Also, I think that insecure port should be always be specified so
the client can identify its own stuff (one might want to use TLS
with protocols without official TLS port).

-Ilari

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Dec 2010 01:02:03 +0100 (MET)

Paul Hoffman wrote:
> opposite. The fact that PayPal has been TLS-only for years has taught
> PayPal users to expect 443, but PayPal is (sadly) in the very small
> minority, so your users are not a good metric.

PayPal is an extremely bad example.

The majority of its use cases (that I've encountered: ebay payments) are
fully vulnerable to sslstrip because of ebay's notorious NON-use of HTTPS.
When used with ebay, paypal isn't accessed through secure bookmarks
and neither through trustworthy user input, but instead by clicking through
a chain of URLs starting on completely untrustworthy HTML pages received
from ebay through plain and vulnerable HTTP.  So an sslstrip attack
is still quite feasible.

>
> Andy Steingruebl wrote:
> >
> > If the sites only does a redirect on port -80 -> 443, the user won't get
> > anything meaningful at port-80 anyway.

An unconditional port 80 -> 443 redirect has some very specific
(and limited) usefulness.  Make it more difficult for users to
bookmark http: (instead of https:) URLs and reduce the
effectiveness of pure passive (=eavesdropping) attacks (like Firesheep).

But one should be careful about "deployed" non-HTTPS URLs not getting
spoiled with 302s.

I've seen a commercial CA that serves you a 302 for a published
CRL Distribution Point
http://<hostname>/<somepath>.crl  -> http://<hostname>/<somepath>2.crl

Any PKI software following a 302 redirect (received over plain HTTP)
exhibits a serious security vulnerability, and it looks like a
CA breakage to actually configure something like this.

-Martin

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Wed, 29 Dec 2010 17:08:21 -0700

> From: Martin Rex [mailto:[email-masked]]
> 
> 
> The majority of its use cases (that I've encountered: ebay payments) are fully
> vulnerable to sslstrip because of ebay's notorious NON-use of HTTPS.
> When used with ebay, paypal isn't accessed through secure bookmarks and
> neither through trustworthy user input, but instead by clicking through a
> chain of URLs starting on completely untrustworthy HTML pages received
> from ebay through plain and vulnerable HTTP.  So an sslstrip attack is still
> quite feasible.

With something like HSTS set/bootstrapped onto client machines already, sslstrip attacks go away.  That said, if the attacker can control the non-paypal source page, they can just modify the link to not be paypal.com at all, no sslstrip necessary.  So sure, that is theoretical, but not something I can fix myself.

- Andy

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Dec 2010 01:17:09 +0100 (MET)

> work machines becomes problematic. So some block TLS entirely.

So everyone is using their private SmartPhone to do HTTPS traffic?
... which also prevents any traces from improper communication
to ever get created on the work machines...

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Dec 2010 01:38:10 +0100 (MET)

> really, really secure but practically unused.

With respect to collision attacks, PKCS#7 and its successor S/MIME,CMS
actually give me slight worries because their dangerous "signedAttributes"
indirect signature design.

With the standardized "randomNonce" signed Attribute (PKCS#9)
you get exactly the wiggle room that you need for precomputed collision
(or preimage) attacks while keeping the signed (and the forged) application
data seperate and pristine from any residual of such attacks.

What could be use cases of a collision attack?

Maybe creating _two_ correctly signed "documents" with a single
signature operation from a "controlled" PKCS7/CMS signature key (and only one
of the signed documents appearing in the official records of the signer...).

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 30 Dec 2010 00:51:02 +0000

Chatting on an iphone all day is somewhat tedious. An iPad on the other hand
- no problem.

I think that is one of the changes that argues for restrictions to be
thought through more carefully. But in general there are a whole rack of
issues that mobile computers are bringing.

Trying to get institutions to take security realistically is really
difficult. Recently we discovered that a French bank had lost over $1.2
billion due to an internal fraud. The relevant compliance records were kept
using a manually updated excel spreadsheet. And last I heard, not a single
one of the people responsible for that fiasco lost their jobs.

Over the last decade the US government has spent over a billion dollars on a
PKI. Yet none of the emails sent out by the US military to journalists are
signed and a low ranking clerk was allegedly able to extract and leak a
quarter million classified diplomatic cables.

We have to deliver security in a form that people are willing to use.

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Dec 2010 01:55:07 +0100 (MET)

Steingruebl, Andy wrote:
> With something like HSTS set/bootstrapped onto client machines already,
> sslstrip attacks go away.  That said, if the attacker can control the
> non-paypal source page, they can just modify the link to not be
> paypal.com at all, no sslstrip necessary.

sslstrip is used to make it _appear_ as if "https://www.paypal.com" is used,
although at the TLS protocol level, a completely different IDNS hostname
is involved.

See page 91ff of this presentation:
http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf

If you're targetting a very specific server, you will _not_ need a
wildcard cert.

>
> So sure, that is theoretical, but not something I can fix myself.

The only difficulty is to actually mount an active attack.

Everything else is easy and straightforward, and a Firesheep-like
tool for it quite possible.

The existing TLS PKI is built on the threat model of pervasive active attacks,
otherwise we could just get rid of all the commercial CAs and simply move
to the SSH-style leap-of-faith on initial encounter that is the predominant
authentication scheme in the offline world of humans and other species.

-Martin

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Thu, 30 Dec 2010 09:42:49 -0700

> although at the TLS protocol level, a completely different IDNS hostname is
> involved.
>
> If you're targetting a very specific server, you will _not_ need a wildcard cert.

Not sure what this has to do with HSTS on PayPal itself?  You're rewriting the source target page, not PayPal.  The attack in a sense isn't directly against paypal.com, but any page that is non-HTTPS that is hosting a link to PayPal.com.  OK, but given that sslstrip is an attack that is about confusing the UI, and a lot of people don't notice when it is in action, faked certificates, etc. aren't really even necessary.

I'm just not sure why you think PayPal is specifically interesting for this attack?  If the user gets MiTM's on a domain that isn't paypal.com, I'm concerned, but there also isn't a lot I can do directly about that in the context of HTTPS, HSTS, etc.  I'll admit ebay.com is a special case of this of course given the relationship between them, and something I'm investigating.

Can you more clearly explain why you think this attack has anything to do with HSTS, and PayPal specifically?

- Andy