Re: [TLS] Working Group Last Call fordraft-ietf-tls-ssl2-must-not-02

t.petch wrote:
> 
> In the same vein as 1), I would like this to update RFC4347; there is a
> presumption that updates to TLS should specify their applicability to DTLS and
> it would be a shame if SSL continued to be used with DTLS.

I'm confused.  AFAIK there is no DTLS version of SSLv2
(and even none for SSLv3, I assume), so this particular
update does not apply to DTLS.

-Martin

> ----- Original Message -----
> From: "Martin Rex" <mrex@sap.com>
> To: "Joe Salowey" <jsalowey@cisco.com>
> Cc: <tls@ietf.org>
> Sent: Monday, October 25, 2010 9:52 PM
> Subject: Re: [TLS] Working Group Last Call fordraft-ietf-tls-ssl2-must-not-02
> 
> 
> > Joe Salowey wrote:
> > >
> > > This is an announcement of WGLC for draft-ietf-tls-ssl2-must-not-02.  The
> draft and its revisions can be found here:
> > >
> > > http://tools.ietf.org/html/draft-ietf-tls-ssl2-must-not-02
> > >
> > > Please send comments to the TLS list by November 17, 2010.
> >
> > This WGLC is about publication of the document, I assume.
> >
> > In principle I'm OK with publication.
> >
> > Re-reading it, I'd like to make two observations:
> >
> > 1. Per document header:
> >        Updates: 5246 (once approved)
> >    this document intends to update rfc-5246 _only_.  The text in
> >    Sections 1 and 3 does not limit itself to implementations of TLSv1.2,
> >    and I would support to similarily discourage the use of SSLv2 for
> >    existing implementations of TLSv1.0 and TLSv1.1.
> >
> >    How about listing TLSv1.0 (rfc2246) and TLSv1.1 (rfc4346)
> >    as well in the Updates: of the document header,
> >    just like RFC5746 (TLS extension RI) does.
> >
> >
> > 2. SSLv2 deficiencies: "Sessions can be easily terminated"
> >
> >     o Sessions can be easily terminated.  A man-in-the-middle can easily
> >      insert a TCP FIN to close the session and the peer is unable to
> >      determine whether or not it was a legitimate end of the session.
> >
> >    I think this exaggerates the usefulness of the closy_notify(0)
> >    warning level alert as used in practice.  By using an application
> >    level framing protocol to mark boundaries of data, it is fairly
> >    easy for application callers to compensate for this "lack" of SSLv2.
> >    Many applications that use a framing protocol look only at their
> >    own framing rather than waiting for the close_notify alert exchange
> >    to _complete_.
> >
> >
> > -Martin
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 