Subject: [keyassure] Commentary about IETF 79 slides

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 21 Nov 2010 15:23:36 +0200

Here's misc. stuff I found from the slides and my own comments to those.

"If you don't have this CA cert in your trust anchor pile, stop: You {SHOULD | MUST} NOT validate my EE cert"

It might be useful not to have that requirement. Like setting private "CA" and chaining certificates to that. Could
make certificate management bit easier.

What attack this is there to defend against?

"In short: does the protocol make things worse if DNSSEC is not used?"

The only scenerios I can come up with:

* Trusting bad authentication data
* Downgrade attacks
* Some extra ways for attacker (that can already DoS) to DoS stuff in new ways.

"Create our own RRType, sub-class CERT, or use TXT with a _prefix"

1) Our own RRType:

+ We can define useful formatting for it.
+ Binary on the wire (efficient in space and time)
- Support for RRType as known type.

2) CERT

- Bad formatting
+ Binary on the wire (efficient in space and time)
- Difficulty of assembling record.

3) TXT with _prefix

+ Well supported RRtype
- Text on the wire (inefficient in space and time)
+ Record is easy to assemble.

"There is discussion of 'I always do Foo over TLS' in DNS"

I still consider this ill-defined.

"The semantics associated with STS-in-DNS should be the same as HSTS; otherwise, the overlap will lead to confusion"

I don't see how DNS version of STS and HSTS could conflict (unless you do something really silly like claiming "I don't support
TLS in DNS and then assering HSTS in HTTP).

But there's more subtle issue. What if you under HSTS rules present self-signed certificate that DNS declares as correct (and
the client security policy trusts DNS)?

The right thing would seem to be to accept it and continue...

"Have to evaluate if the HTTP semantics apply to other application protocols that run under TLS"

My opinion on that: Definitely not! (and that's where that "ill-defined" comes from).

-Ilari