Re: [TLS] TLS 1.3 - Support for compression to be removed

[Salz, Rich]

 
> Well, it is true that NNTP can stay on TLS 1.2.  News clients and news servers
> can implement TLS 1.2 and use it.
> The concern will be when TLS 1.2 is declared "flawed".  Maybe one day it will
> be considered insecure; and then, compliant TLS implementations won't be
> able to use compression.  That facility will then be lost.

Yes.

It is widely recognized that in many cases, TLS-level compression is flawed 
(for example NNTP authinfo?).  TLS 1.3 does not have it.  So NNTP that needs 
compression can continue to use TLS 1.2, and if TLS 1.2 is "flawed" things can 
change.

/r$

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Dave Garrett]

On Saturday, September 19, 2015 04:06:37 pm Salz, Rich wrote:
> On Friday, September 18, 2015 04:25:39 pm Julien ÉLIE wrote:
> > The concern will be when TLS 1.2 is declared "flawed".  Maybe one day it 
> > will
> > be considered insecure; and then, compliant TLS implementations won't be
> > able to use compression.  That facility will then be lost.
> 
> Yes.
> 
> It is widely recognized that in many cases, TLS-level compression is flawed 
> (for example NNTP authinfo?).  TLS 1.3 does not have it.  So NNTP that needs 
> compression can continue to use TLS 1.2, and if TLS 1.2 is "flawed" things 
> can change.

Contrary to its name, TLS is not a transport protocol. It's a security 
protocol, and compression is not a security feature. (though, when combined 
with padding, I could see how it could be useful) It didn't belong in the spec 
like it was, even if it worked safely. It might be doable in a TLS extension, 
but I don't think this is a great idea. Application protocols can handle 
compression better and more safely, as they can actually know what they're 
doing and how to properly compress it.

Even if TLS compression could be fixed, the old insecure junk doesn't magically 
go away. It needs to be treated as ruined forever, just to be safe, as far as 
I'm concerned. If you need compression, I wouldn't recommend relying on it here.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Should we require implementations to send alerts?

[Kurt Roeckx]

On Wed, Sep 16, 2015 at 01:54:20PM +0200, Florian Weimer wrote:
> On 09/16/2015 01:51 PM, Henrik Grubbström wrote:
> > On Wed, Sep 16, 2015 at 12:02 PM, Florian Weimer  wrote:
> >> On 09/15/2015 06:29 PM, Nico Williams wrote:
> > [...]
> >>>
> >>> But if you have a fatal error you'll be closing immediately anyways.
> >>> Does sending the fatal alert cause a problem other than increase the
> >>> likelihood of RSTs?  What is the alternative considering that the next
> >>> step is to close the connection anyways?
> >>
> >> I'm trying to explain that any requirement to send fatal alerts will be
> >> difficult to implement.  With the BSD sockets API, the only way to do
> >> that reliable is *not* to close the socket immediately, which is
> >> apparently not what you (or existing APIs) expect, and which is where
> >> the difficulty lies.
> > 
> > What about SO_LINGER?
> 
> With full-duplex connections, it does not make a difference.  TCP will
> still detect a data loss event, send the RST segment, and discard the
> queued fatal alert.

>From what I understand, the RST is send after calling close(),
shutdown(SHUT_RD) or shutdown(SHUT_RDWR) and not all data has
been read from the socket or more data is received.

So my understanding of making sure the other end receives it is
calling close() when read() returns 0 (or an error).  You might
want to do shutdown(SHUT_WR) before that to indicate you're not
going to send anything anymore, but that should have no effect
since the other end is supposed to close the connection after
receiving the alert anyway.  You might want to have a timeout and
close it anyway.  If read() returns any data, you should of course
throw it away.

It seems that when you using SO_LINGER you might end up turning
your non-blocking socket into a blocking one on close() (or
shutdown?), and can't even tell if it was received succesfully or
not.

But I wonder in which cases it's important to receive the fatal
alert.  I guess it's the cases where it can tell you that
connecting again might work, and so would only be during the
handshake.  The only case I can think of is something like "client
certificate required", and as far as I know we don't even
currently have something that says that explicitly.


Kurt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Julien ÉLIE]

Hi Loganaden,


If compression is dropped at the TLS layer, you can still do it at
the layer above it.

Indeed. And, it's probably a better idea to do it in the layer above.


Then how will the news server know that the client is compressing data 
after the use of STARTTLS where a security layer without compression has 
been negotiated?
It cannot guess it; and it won't try all uncompression methods to see 
which one has been used.


Unless you are speaking of an update of the NNTP protocol to add a new 
compression capability (for instance with the use of a new COMPRESS 
command with possible arguments), that could be used by clients?
Well, it will require some work to specify it.  Not to speak of its 
implementation afterwards.


I bet other protocols would also need similar new specifications to 
explain how compression can be enabled.


--
Julien ÉLIE

« Etna : lave dévalante. »

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls