Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16

[Eric Rescorla <[e-mail]>]

On Mon, Apr 16, 2018 at 5:22 PM, Peter Saint-Andre <[e-mail]>
wrote:

> Hi Marc, a few further comments inline.
>
> On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote:
> > Hi Peter,
> >
> > Thanks for the review and sorry for the delay in responding, I was
> traveling for the last 4 weeks.
> >
> > See my responses inline.
> >
> > On 04/02/2018 03:59 PM, Peter Saint-Andre wrote:
> >> Reviewer: Peter Saint-Andre
> >> Review result: Ready with Nits
> >>
>
> <snip/>
>
> >> The first paragaraph of Section 6.2.3 restates recommendations from RFC
> >> 7525; why not simply reference that specification?
> >
> > The original text in RFC5389 said this:
> >
> > " When STUN is run by itself over TLS-over-TCP, the
> >   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a
> >   minimum. [...]"
> >
> > The new text is an attempt at updating it in the same spirit of giving
> minimal instructions and complementing them with a reference to RFC 7525 -
> which was the reason for the reference to RFC 7525 there.
> >
> > So I kept the text there, followed by the following paragraph, in
> addition of moving the original last paragraph in the Security
> Consideration section:
> >
> > " These recommendations are just a part of the the recommendations in
> >   [RFC7525] that implementations and deployments of a STUN usage using
> >   TLS or DTLS SHOULD follow."
>
> I would instead suggest that we do something like Section 2 of RFC 7590
> for XMPP:
>
>    The best current practices documented in the "Recommendations for
>    Secure Use of TLS and DTLS" [RFC7525] are included here by reference.
>    Instead of repeating those recommendations here, this document mostly
>    provides supplementary information regarding secure implementation
>    and deployment of XMPP technologies.
>
> Here's the rationale: RFC 7525 is likely to be updated/replaced more
> quickly than STUNbis. If STUNbis recommends a particular cipher suite
> that 7525bis stops recommending, in the absence of STUNter will STUN
> implementations keep following STUNbis or will they upgrade to whatever
> 7525bis recommends? I suggest it will be the former, which is not what
> we want.
>

I forgot about this in my review, but you should also profile ciphers for
TLS 1.3.

-Ekr

>> Section 6.3.4 states:
> >>
> >>    o  If the error code is 500 through 599, the client MAY resend the
> >>       request; clients that do so MUST limit the number of times they do
> >>       this.
> >>
> >> It is reasonable to provide guidance as to the number of re-sends?
> >
> > Same issue here, that's a section that is unmodified from RFC 5389.
>
> I understand. Now is our chance to fix it. :-)
>
> >  As long as the client does not enter an endless loop of retransmission,
> choosing different numbers of re-sends does not affect interoperability.
>
> Choosing different numbers is OK, but choosing an infinite number is
> not. Can we provide guidance as to how many is too many? 10? 50? 100?
>
> >> Section 9.1.1 and other sections invoke the OpaqueString profile of the
> >> PRECIS FreeformClass; it might be helpful to mention that the profile is
> >> used to handle Unicode characters outside the ASCII range, and that no
> >> changes result if only ASCII characters are used.
> >
> > Hmm.  But in that case the application has first to test that the string
> is in the ASCII range.  Isn't that better to always assume that the input
> string will contain Unicode, and let the implementation of OpaqueString
> short-circuit the processing in the case of an all-ASCII string?
>
> Yes, I meant that as an informational note to implementers so they would
> worry less. But it's not necessary and I think you can safely ignore it.
>
> Peter
>
>