Session Traversal Utilities for NAT (STUN)
draft-ietf-behave-rfc3489bis-18

I'm not a big fan of using a separate port for a TLS-variant of the
protocol.  There's some discussion of the design and perception
problems that introduces in RFC 2595.  I also think the best proposal
I've seen for an in-band start-tls style mechanism is:
 http://tools.ietf.org/html/draft-fanf-smtp-quickstart-a-00
which minimizes extra round-trips while remaining compatible with typical
TLS stacks.  I suspect auto-detecting the different packet formats
between TLS and some other protocol is unlikely to work in practice
with many deployed TLS stacks, so I question the usefulness of such a
proposal.

Because the Internet clearly makes do with separate SSL and non-SSL
ports for http (just as it survived when http had no support for
persistent connections), this doesn't quite reach a discuss-level
problem in my book.  But it's not a good design in my opinion.

It says:
    If DNS was not used,
   the client MUST be configured with a set of authorized domains whose
   certificates will be accepted.
But if the cert had an ip address in it, this would not be needed.

I would make the TCP error timeout of 39500ms configurable because I doubt many implementation are going to wait this long before trying the next server that DNS provided.

1. DNS-DIR expert Peter Koch made a detailed review on version 11 of the draft. While the principal issues have been resolved, there are still a number of observations that would better be taken into consideration if a revised version is issued (as it looks to be the case taking into consideration the quantity and quality of the other comments): 

> Limited support here. I've posted a review of -11 to this directorate (copying
Magnus) on 18 OCT pointing out that the handling of SRV RRs, including the prefix naming scheme was in conflict with RFC 2782. First I missed the mailed response and then I lost track, but it seems much of this is addressed in
-13 now, where one proposed solution to the prefixing problem is to change registered port name in the IANA database. That's for IANA and the guards of port name/number assignment to decide. The use of "stuns" still isn't in line with 2782, but looks better than the earlier approach of defining a new "service" _tls.

I still can't follow the criticism of 2782 on "failure" expressed in section 9, but it's probably non-normative enough not to bounce back in the future.

The remaining issue I have is the A/AAAA fallback in case there's no SRV RR present.  This kind of default bites (see MX) and is welcome during phase-in but usually later regretted.  Admittedly I didn't follow WG discussion on this topic.


There is one other draft on the agenda that touches upon DNS, but I'm not sure whether it's just unfortunate wording or a misperception.
"Identity-based Encryption Architecture" <draft-ietf-smime-ibearch-06.txt> says in section 2.1:

        A logical architecture would be to have a PKG/PPS per a 
        name space, such as a DNS zone. The organization that 
        controls the DNS zone would also control the PKG/PPS and 
        thus the determination of which PKG/PSS to use when 
        creating public and private keys for the organization's 
        members.

It's the overview section, there's no immediate protocol spec following, but it appears as operational advice and whenever name space or DNS administrative boundaries are mapped to organizational boundaries that makes me nervous a bit.

2. I have an operational concern about the transition from 3489 to 3489bis. When is it required, how does it happen in an existing deployment, is there a migration strategy or critical aspects that need to be considered in the migration. I believe that this is reflected in Cullen's DISCUSS by: 

> Uh, and the one all important detail, I don't think we have a usage defined anywhere for a server to replace a 3489 STUN server

Section 10, paragraph 1:
> A STUN transaction over UDP is also considered failed
> if there has been a transport failure of some sort, such as a fatal
> ICMP error.

  Please clarify exactly which ICMP errors you consider to be fatal.
  (You probably mean what RFC1222 calls "hard" errors?)


Section 2818, paragraph 1:
> However, for a request/response transaction, if the client has not
> received a response 7900ms after it sent the SYN to establish the
> connection, it considers the transaction to have timed out.  This
> value has been chosen to equalize the TCP and UDP timeouts for the
> default initial RTO.

  This may need to be adjusted based on what the resolution to my
  DISCUSS on the UDP RTO is.


Section 7.3.1., paragraph 3:
> If the request uses UDP transport and is a retransmission of a
> request for which the server has already generated a success response
> within the last 10 seconds, the server MUST retransmit the same
> success response.

  10 seconds may need to be changed based on the outcome of the RTO
  DISCUSS above. (Value needs to be larger than max (client retransmit
  attempts, MSL).


Section 17.4., paragraph 0:
> 17.4.  STUN UDP and TCP Port Numbers

  Why aren't we allocating a port for "stuns" here?

  The recent attacks on MD5 do not impact the use of the algorithm
  as it is used here.  However, one should consider how a transition
  from MD5 to another one-way hash function might be accomplished in
  the future.

The specification notes that Classic STUN had security problems, and the "solution"
proved overly complex, but never describes those problems.  It would be very helpful
to the reader if that information was explicitly included in the document.  Without that
information it isimpossible to determine whether this specification avoids the same
pitfalls.