Re: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt

[Paul Hoffman <[e-mail]>]

On 1/25/11 7:39 AM, Eliot Lear wrote:
> 1.  The draft states that DNSSEC MUST be used, and there is some logic
> to this.  If you have an unprotected communication then it is possible
> for both an upgrade DOS attack and downgrade MITM attack.  That having
> been said, let's at least note that this is a substantial gating
> function to implementation.

At the time I wrote this, I thought that there would be agreement in the 
DNSEXT WG to help make sure that DNSSEC was used end-to-end. It now 
seems there is no interest in pursuing that. So, I will downgrade this 
to a security consideration that says that relying on this 
security-related information, if gotten insecurely, gives an attacker a 
different way to perform a downgrade attack.

> 2.  I don't understand unde what circumstances CFB would be used.  The
> reason that such fallback mechanisms exist is because the client doesn't
> have knowledge of what server capabilities are.  In this case, the
> server through DNS is expressing its capabilities to the client, so when
> is CSO applicable?

No client *needs* to use HASTLS: it is useful for making decisions when 
things go wrong. A HASTLS query might be made by a CSO client when they 
can't reach a site they thought had a TLS service (such as if they had 
been there before); a CFB client would want to do a HASTLS query before 
falling back to insecure; a CIO client might do a HASTLS query before 
trying to communicate at all.

> 3.  The presentation form of the new RR is not self-explanatory.  Might
> I recommend something like (servicename-or-number/protocol TLS=port#
> plain=port#).

See my earlier response to Patrik.

> 4.  In the case of a hostname that offers many services and may be in
> some way virtualized, the client may have to sift through quite a number
> of 3-tuples to retrieve relevant information.  Another approach would be
> to make use of a DKIM-like approach in the RR label, although one would
> have to take care that a label not contain all numbers (I seem to recall
> that's not allowed).

I think that returning an RRset would solve both your concern and 
Patrik's concern about variable-length responses.

  5.  Perhaps most important, this service should be generalized in a
> different way.  What is being proposed here is a host connection policy
> record.  TLS is not the only issue.  Another issue would be whether SCTP
> is in use for a given, for instance.  I wonder if this draft should be
> recast in a more extensible approach, so that a host doesn't need to
> query for a bunch of records (TCP, DTLS, SCTP, etc.).

That is certainly an option. I tend to shy away from kitchen-sink 
approaches, but doing so means that there then needs to be many more 
RRtypes. This balance is based on preference, not protocol needs. The WG 
should certainly be the ones to say which style preference should be 
used in the protocol.

> 6.  Along these lines we should view this as an evolution of SRV.

Errr, just to be clear: are you proposing that this be an update to RFC 
2782? If so, please give a straw-man for how that would work. I don't 
see how SRV records are extensible.