Re: [keyassure] Asserting DANE exclusivity for an entire domain

[Paul Wouters <[e-mail]>]

On Wed, 9 Feb 2011, Martin Rex wrote:

>>>> I agree with this, but the question is how do you present an empty list.
>>>
>>> What exactly would you want to convey with an empty list?
>>>
>>>  "I won't respond to TLS, so don't even bother trying"
>>
>> More precisely, "there is no TLS service associated with this DNS
>> name/transport/port".  Therefore, general-purpose clients that refer to
>> TLS services by DNS name/transport/port will not be able to make a
>> connection.

What's wrong with an NSEC record for the TLSA/HASTLS record saying that?

> I should have been more explicit on this:
>
> There is a client with a desire to communicate, and a preference/intend
> for TLS-protection.  But with most protocols, there is a fallback
> strategy to communicate without TLS.  It could be that the initial
> reference does not even imply TLS, and its only the client who is
> looking for clues in DNS whether TLS is available.

This is why in HASTLS, you can state whether or not there is a fallback you
may use.

> So I'm still wondering: what message should an empty list convey?
>
> A pre-DANE client might fallback to non-TLS if TLS doesn't work,
> or it might not try TLS at all.
>
> What should a DANE-aware client, that is wildly determined to communicate
> do when finding an empty TLSA record?  Go straight for the unprotected
> communication (which is what such a record would imply), or bother
> the user with an annoying popup before doing the fallback on unprotected
> communication.

An empty TLSA record offers nothing more over an NSEC record.

> I doubt that "not communicating at all" is a workable solution for such
> clients, because it is likely to be perceived as a usability problem
> by a non-marginal fraction of the user base.

Yet, that is what security will require. If a TLSA record states there is
TLS, or a DNSSEC error occurs trying to get a TLS related record, you
SHOULD NOT fallback to plaintext.

The usability issue is in running legacy port 80..... Fix that and your problem
will go away. Then at most the user will see a bad/hacked cert with a popup,
hopefully preventing the user from connecting.

> Most "Web users" think that "the Web" == "the Internet" and are so completely
> accustomed to trust everyone with everything over completely insecure
> communication channels (commonly described with "http://")
> that it is going to be hard to turn back time on this.

HASTLS and STS are bascially the start of the end of port 80.

> I'm currently quite annoyed of my EMail provider, because their Web-Mail
> interface completely refuses to serve a login page via HTTPS:
> They do "POST" to a HTTPS url on their Login-Page, but that page itself
> is accessible only through HTTP (on a host that does not listen on 443).

Tell them that is unacceptable.

Paul