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

[Hubert Kario]

On Friday 18 September 2015 15:13:37 Bill Frantz wrote:
> On 9/18/15 at 4:27 AM, hka...@redhat.com (Hubert Kario) wrote:
> >except that a TLS1.3 version intolerant implementation won't
> >show its ugly head until TLS1.4 gets deployed
> 
> Is there a reason a test suite can't offer TLS 1.4, even if we
> don't know what it is?

There is no reason. In fact, any test suite should basically start with 
this (it being one of the very first fields the server needs to handle).

> The TLS implementation under test should
> gracefully step back to TLS 1.3.

correct

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hubert Kario]

On Friday 18 September 2015 13:24:33 Brian Smith wrote:
> On Fri, Sep 18, 2015 at 4:36 AM, Hubert Kario  
wrote:
> > On Friday 18 September 2015 00:58:19 Martin Rex wrote:
> > > Easier troubleshooting is IMO a sufficient rationale to justify
> > > existence of the alert mechanism and a "SHOULD send the alert
> > > before
> > > closing the network connection".
> > > 
> > > A "MUST send fatal alert" requirement, however, would be silly
> > > (and
> > > will be void in face of rfc2119 section 6 anyway).  What would be
> > > the semantics of such a requirement anyway?
> > 
> > That's true only if you ignore the situation when TLS 1.4 or TLS 2.0
> > is deployed.
> 
> > So yes, it's no a direct interoperability issue, but it will become
> > one
> > in the future.
> 
> Given a *conformant* TLS 1.3 implementation, that kind of
> interoperability problem could only happen if the TLS working group
> specifically designed it to happen. In particular, a conformant TLS
> 1.3 implementation must accept larger values of
> ClientHello.client_version.

Given that there is no *conformant* TLS 1.2 implementation that is 
widely deployed[1], I won't hold my breath for there being many TLS1.3 
ones either.

We don't live in ideal world, lets build protocols that can handle 
breakage. Lets make specifications that have the sticks that we can hit 
developers with when they do wrong.

 1 - NSS, SChannel and OpenSSL, all ignore some MUSTs in TLS1.2
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
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] Should we require implementations to send alerts?

[Florian Weimer]

On 09/16/2015 09:53 PM, Brian Smith wrote:

> Assume the client and the server implement the mandatory-to-implement
> parameters and that both the client and the server are otherwise
> conformant. In this scenerio, when would an alert other than the non-fatal
> close_notify be sent?

I have been told that mandatory-to-implement does not mean
mandatory-to-enable, and that it is possible to run a nominally
RFC-conforming client or server in a mode which is not interoperable
with anything else.  Under such a scenario, fatal alerts happen without
an attack.

Most fatal alerts in the wild appear to be harmless in the sense that
they are not due to attacks, but due to interoperability failures (due
to not enabling mandatory-to-implement cipher suites, self-signed
certificates, incomplete certificate chains, or just bugs).

-- 
Florian Weimer / Red Hat Product Security

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

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

[Hubert Kario]

On Wednesday 16 September 2015 12:53:53 Brian Smith wrote:
> Thus, the empirical evidence from Mozilla's
> widely-deployed implementation shows that (a) the requirement to send
> alerts is difficult to conform to, and (b) it is unimportant in
> practice to send alerts.

and yet Firefox depends on them to report human-readable errors to users 
when it can't connect to a server...

Making the alerts more predictable and with more pinned down meanings 
will only _help_ the opportunistic HTTPS and HTTPS-by-default campaigns.

yes, we need to be careful about alerts that provide information about 
secret data, but there's very little of such data during handshaking, 
where the vast majority of alerts apply and where they are most useful
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

On Wed, Sep 16, 2015 at 12:53:53PM -0700, Brian Smith wrote:
> Further, the alerting mechanism has encouraged the unsafe practice of
> "version fallback." It is clear from looking at the bug databases of
> Firefox and Chrome that their attempts to make security decisions based on
> what alerts they received was bad for security.

Do we think that silent connection closings wouldn't also lead to
version fallback?

"Let's try this.  Nope, didn't work.  Let's try this other thing...
Nope, didn't work.  ..."

Fatal alerts are quite handy for diagnostics on the client side, really.
I'd rather keep them than remove them, but I'd be OK with clients never
sending them.  I'm OK with fata alerts being SHOULD send.  I'm OK with
having text explaining how to send them such that peers (clients) will
get a fair chance of receiving them.

We shouldn't always fight the last war.

I hope the browsers won't implement reconnect version fallbacks again,
ever.

Nico
-- 

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

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

[Nico Williams]

On Sat, Sep 12, 2015 at 01:49:49PM -0700, Eric Rescorla wrote:
> Issue: https://github.com/tlswg/tls13-spec/issues/242
> 
> In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
> 
> "Nobody must ever be *required* to send an alert. Any requirement for
> sending an alert should be SHOULD, at most."

There have been two main lines of argument in this thread, paraphrased:
a) don't send them, they are dangerous, and b) making it even just
likely that fatal alerts reach the peer is hard, therefore why bother.

I believe (a) is flawed and wrong.  Fatal alerts are not the cause of
version fallback reconnects, and they should not be a problem with any
of the ciphersuites in 1.3.

I believe (b) is no reason not to send the fatal alerts.  It is reason
to have text about how an implementation that cares can improve the
likelihood of the peer receiving them.

Yes, fatal alerts should be required to be sent.  Servers should be
encouraged to improve the chances of the alerts being received by
clients by attempting to delay close the connection.  (A simple timer is
not enough; a hard limit on the number of pending-close connections is
desirable.  IMO.)

Nico
-- 

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

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

[Brian Smith]

On Thu, Sep 17, 2015 at 3:00 PM, Nico Williams 
wrote:

> On Sat, Sep 12, 2015 at 01:49:49PM -0700, Eric Rescorla wrote:
> > Issue: https://github.com/tlswg/tls13-spec/issues/242
> >
> > In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
> >
> > "Nobody must ever be *required* to send an alert. Any requirement for
> > sending an alert should be SHOULD, at most."
>
> There have been two main lines of argument in this thread, paraphrased:
>

It is amusing when people pull this trick, but it gets old. There are more
than two lines of argument against sending alerts, and your paragraphing
mischaracterizes them.

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

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

[David Benjamin]

(Resending from the right address, again. Possibly I should have subscribed
with the other one...)

On Thu, Sep 17, 2015 at 6:23 PM David Benjamin  wrote:

> On Thu, Sep 17, 2015 at 5:46 PM Brian Smith  wrote:
>
>> On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams 
>> wrote:
>>
>>> On Wed, Sep 16, 2015 at 12:53:53PM -0700, Brian Smith wrote:
>>> > Further, the alerting mechanism has encouraged the unsafe practice of
>>> > "version fallback." It is clear from looking at the bug databases of
>>> > Firefox and Chrome that their attempts to make security decisions
>>> based on
>>> > what alerts they received was bad for security.
>>>
>>> Do we think that silent connection closings wouldn't also lead to
>>> version fallback?
>>>
>>
>> Let's ask the browser vendors:
>>
>> Browser vendors, if web servers were to stop sending alerts during
>> handshake failures, would you start doing version fallback when a
>> connection is closed?
>>
>
> Connection close is already a fallback trigger.
>
>
>> Fatal alerts are quite handy for diagnostics on the client side, really.
>>>
>>
>> I agree that they are often marginally useful. However, the risks
>> associated with the alert mechanism outweigh those benefits.
>>
>
> I don't think the existence of alerts at all increases the "risk" that
> people will do fallbacks. I think you've got causality flipped. It wasn't
> "we get alerts, ergo we can get away with a fallback" but "Servers are
> dumb, we want to fallback. If there's something easy we can do to constrain
> when fallbacks happen, we should. Being more lenient means even more
> unexpected dependencies on the fallback may crop up. (Not that this hasn't
> happened anyway.)".
>
> Besides, fallback conditions tend to be extremely liberal in my
> experience. Which makes sense since it's used against buggy servers. If a
> buggy server blew up because it's version-intolerant, it's not likely to be
> kind enough to tell you that.
>
> While I don't see much use in "your records don't authenticate" and
> "that's not even a syntactically valid ServerKeyExchange!", not all
> failures are protocol failures. There's also negotiation failures when
> parameters aren't okay. When removing cipher suites or bumping minimum
> versions, it's nice to show a dedicated error message when it goes wrong.
>
> And client certs break (even more) if you can't distinguish network errors
> from the peer complaining at you. I wish they would go away, but I'm stuck
> with supporting it right now and I doubt the world will rally behind
> "client certs on the web are deprecated; you do not get TLS 1.3 if you use
> client certs".
>
> David
>
>
>>
>>
> I'd rather keep them than remove them, but I'd be OK with clients never
>>> sending them.  I'm OK with fata alerts being SHOULD send.
>>
>>
>> I suggest that, at most, implementations SHOULD NOT send them. IMO it
>> would be better to remove the alert mechanism altogether in TLS 1.3.
>>
>> Most people that are arguing for retaining the alert requirements seem to
>> be concerned about alerts sent from the server to the client. Does anybody
>> think it is important to require clients to ever send alerts other than
>> close_notify?
>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Brian Smith]

On Thu, Sep 17, 2015 at 3:15 PM, Dave Garrett 
wrote:

> On Thursday, September 17, 2015 06:00:05 pm Brian Smith wrote:
> > There's no evidence that the presence or absence of an alert when a
> > connection is closed makes any positive difference in the security of any
> > non-secure fallback mechanism. Keep in mind that the alerts during the
> > handshake are NOT authenticated, and the TLS threat models thus assumes
> > that the attacker can remove or alter them.
>
> The whole handshake is retroactively authenticated upon completion. Just
> because an attacker can muck up the attempt to connect, doesn't mean all
> hope is lost.
>

A fatal alert during the handshake is never authenticated, because (a) the
alert record is the last record sent (i.e. there is no Finished message
sent afterward to authenticate it), and (b) The handshake hashes only cover
Handshake records, not Alert records.


> The primary benefit with the version alert, specifically, is that it
> allows a client to at least have a clue as to what to attempt.
>
> Without alert:
> client tries
> server stares blankly into the void and/or drops abruptly
> now, what does the client do? try again as-is, or try again with old stuff?
>

A conformant TLS 1.3 implementation will not be version intolerant. If the
client does insecure version fallback in response to an alert or connection
close by a conformant TLS 1.3 implementation then it is guaranteed to be
doing the wrong thing.


> Sure, a MitM could try to downgrade by injecting an unauthenticated alert
> into the mix, but the handshake will fail once that is authenticated at the
> end.
>

This is not how the protocol works at all. The alert is unauthenticated,
full stop.

The only time an alert is authenticated is when it is sent after the
Finished message. But then, since such alerts can be triggered by a MitM
who does not have knowledge of the keys, such sending of alerts allows the
MitM to effectively inject known plaintext (the alert record) into the
connection, which runs the risk of facilitating attacks.


> Just as the obvious footnote: it's impossible to make any of this
> resistant to an attacker killing the connection. Just assume that's always
> possible, at minimum with wirecutters. The goal is security or bust. Alerts
> give clients the confidence to actually bust when they have to.
>

In general, the "when to bust" is "always."

Again, there is no such thing as a secure non-secure fallback.

Cheers,
Brian
--
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

On Thu, Sep 17, 2015 at 03:00:05PM -0700, Brian Smith wrote:
> On Thu, Sep 17, 2015 at 2:55 PM, Nico Williams 
> wrote:
> > On Thu, Sep 17, 2015 at 05:47:50PM -0400, Dave Garrett wrote:
> >
> > Yes, exactly.  Thanks.
> >
> 
> There's no evidence that the presence or absence of an alert when a
> connection is closed makes any positive difference in the security of any
> non-secure fallback mechanism. Keep in mind that the alerts during the
> handshake are NOT authenticated, and the TLS threat models thus assumes
> that the attacker can remove or alter them.

I thought your argument was that their presence led to version
fallbacks.  My response is that silent connection closes will too.

My apologies if I misunderstood your argument.

> > User certificates will be useless without alerts for validation or
> > authorization failures.
> 
> First, this is due to flaws in the design of applications and TLS in how
> client certificates are handled.

Yes: they shouldn't be relying on TLS to authenticate users.  Got it.

:^)

Nonetheless, there is the feature, and if we have it then we might as
well build it right, which includes meaningful error messages.

> Secondly, if a server doesn't deal with client certificates, why
> should it be forced to send alerts?

That was just one case.

> > > We could probably build a whole list here, but that's enough for me to
> > > say that alerts matter in conformant implementations and that we need
> > > to always expect they're used correctly.
> 
> Again, the alerts are generally unauthenticated so there is really no
> correct use of them.

Diagnostics.  And not all alerts need be unauthenticated.  And heck, we
could have the server send signed alerts in handshake failure cases.

Nico
-- 

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

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

[Brian Smith]

Martin Thomson  wrote:

> On 17 September 2015 at 14:46, Brian Smith  wrote:
> > Browser vendors, if web servers were to stop sending alerts during
> handshake
> > failures, would you start doing version fallback when a connection is
> > closed?
>
> I'm not sure.  We still have a small amount of vestigal fallback code
> in our code.  We are gradually killing version fallback off and
> removing alerts would likely set that effort back.
>

Actually, Firefox has already stopped doing version fallback completely for
all versions of TLS it supports, unless the website is on a whitelist.
That's not really "gradually."

We're not sure where we stand with version fallback and 1.3.  We don't
> know how much version intolerance 1.3 will generate.  That at least
> might not depend on alerts, though we don't know just yet.
>

A conformant TLS 1.3 implementation cannot be version intolerant. If it
were version intolerant then it would not be a conformant TLS 1.3
implementation. So, conformance requirements for TLS .1.3 servers don't
matter as far as version intolerance is concerned.


> I don't see much support for the notion that forbidding alerts is a
> good idea.  We use alerts quite a bit for basic diagnosis.  Bad
> configurations are pretty commonplace, the most common being one where
> there is no common cipher suite.  Being able to isolate the error that
> is pretty useful.
>

I still think it is better to recommend to never send alerts. But, at least
there are good reasons (which I gave much earlier in the thread) for why a
server would choose not to send alerts, e.g. out of an abundance of
caution. So, "MUST send" is clearly too far.

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Brian Smith]

On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams 
wrote:

> On Wed, Sep 16, 2015 at 12:53:53PM -0700, Brian Smith wrote:
> > Further, the alerting mechanism has encouraged the unsafe practice of
> > "version fallback." It is clear from looking at the bug databases of
> > Firefox and Chrome that their attempts to make security decisions based
> on
> > what alerts they received was bad for security.
>
> Do we think that silent connection closings wouldn't also lead to
> version fallback?
>

Let's ask the browser vendors:

Browser vendors, if web servers were to stop sending alerts during
handshake failures, would you start doing version fallback when a
connection is closed?

Fatal alerts are quite handy for diagnostics on the client side, really.
>

I agree that they are often marginally useful. However, the risks
associated with the alert mechanism outweigh those benefits.


> I'd rather keep them than remove them, but I'd be OK with clients never
> sending them.  I'm OK with fata alerts being SHOULD send.


I suggest that, at most, implementations SHOULD NOT send them. IMO it would
be better to remove the alert mechanism altogether in TLS 1.3.

Most people that are arguing for retaining the alert requirements seem to
be concerned about alerts sent from the server to the client. Does anybody
think it is important to require clients to ever send alerts other than
close_notify?

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

On Thu, Sep 17, 2015 at 02:46:39PM -0700, Brian Smith wrote:
> On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams 
> wrote:
> > Do we think that silent connection closings wouldn't also lead to
> > version fallback?
> 
> Let's ask the browser vendors:
> 
> Browser vendors, if web servers were to stop sending alerts during
> handshake failures, would you start doing version fallback when a
> connection is closed?

That's not how we answers to questions like that.  These behaviors (on
the part of developers) arise long after we think ask the question.

The point is: if they did it then, why would we think they wouldn't do
it now without fatal alerts?

Spoiler alert!1!!: developers want the user experience to be smooth,
security be damned, so yes, they will in fact implement version
fallbacks on connection close.

But now consider a fatal alert that conveys a "it's not gonna work with
earlier versions either, you dummy" message.  That's got a slightly
better chance of working.

Nico
-- 

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

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

[Brian Smith]

On Thu, Sep 17, 2015 at 2:55 PM, Nico Williams 
wrote:

> On Thu, Sep 17, 2015 at 05:47:50PM -0400, Dave Garrett wrote:
> > On Thursday, September 17, 2015 03:27:10 pm Brian Smith wrote:
> > > (We should focus on conformant implementations because non-conformant
> > > implementations can do whatever they want, by definition).
> >
> > The flaw in your logic here is the fact that specifications change.
> > Firefox will receive a protocol_version alert from a
> > version-incompatible server. Both implementations could be fully
> > conformant to their target specifications, just different versions.
> > Without this alert being consistently sent, everyone gave up and
> > implemented a sloppy fallback mechanism which made downgrade attacks
> > rather simple.
>
> Yes, exactly.  Thanks.
>

There's no evidence that the presence or absence of an alert when a
connection is closed makes any positive difference in the security of any
non-secure fallback mechanism. Keep in mind that the alerts during the
handshake are NOT authenticated, and the TLS threat models thus assumes
that the attacker can remove or alter them.


> > Certificate alerts can happen pretty much anywhere and this is a
> > user-configurable area so it's not the implementations fault, but it
> > needs to know what happened for anyone to be able to handle it.
>
> User certificates will be useless without alerts for validation or
> authorization failures.
>

First, this is due to flaws in the design of applications and TLS in how
client certificates are handled.

Secondly, if a server doesn't deal with client certificates, why should it
be forced to send alerts?


> > We could probably build a whole list here, but that's enough for me to
> > say that alerts matter in conformant implementations and that we need
> > to always expect they're used correctly.


Again, the alerts are generally unauthenticated so there is really no
correct use of them.

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nico Williams]

On Wed, Sep 16, 2015 at 12:02:57PM +0200, 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.
> 
> 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.

*Sending* the fatal alert is not hard at all.  Giving the peer a fair
chance to get them is the difficult thing.  Strictly speaking then,
requiring that fata alerts be sent is not difficult to implement.  :^)

Tongue-in-cheek aside, I think it's fair to say that fata alerts SHOULD
be sent rather than MUST be sent.  And it's a good idea to explain that
sending a fatal alert, by itself, does not really mean that the peer is
even more likely than not to see it, that more effort is required by the
sender to give the peer a fair chance of seeing it.

Fatal alerts are useful for diagnostics purposes at least, but there's
no real need to tell a peer why you're slamming the door on them, is
there.

Nico
-- 

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

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

[Hanno Böck]

On Sat, 12 Sep 2015 13:49:49 -0700
Eric Rescorla  wrote:

> Issue: https://github.com/tlswg/tls13-spec/issues/242
> 
> In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
> 
> "Nobody must ever be *required* to send an alert. Any requirement for
> sending an alert should be SHOULD, at most."

Just a quick thought on this: We had vulns in the distant past that
relied on different reactions to different errors (Vaudenay / Padding
Oracle attack).

The Vaudenay attack is history because we agreed long that CBC/HMAC
with MAC-then-Encrypt will be gone. But I think making the error alert
optional may lead to similar attacks. An implementation may decide to
send an error alert in one situation and no error in another. This
may leak information valuable to an attacker.

I generally think having a more strict spec with less wiggle room is
better. Therefore: I think a MUST is better.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpwV5RTpF9Bz.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Andrei Popov]

I generally agree that sending alerts is the right thing for an implementation 
to do, for all the reasons discussed on this thread. It is also helpful when 
RFCs specify the appropriate alerts for various conditions.

On the other hand, it seems unimportant whether an alert is defined as a SHOULD 
or a MUST: either way the peer can't enforce the use of alerts.

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dave Garrett
Sent: Saturday, September 12, 2015 7:22 PM
To: tls@ietf.org
Cc: Geoffrey Keating <geo...@geoffk.org>
Subject: Re: [TLS] Should we require implementations to send alerts?

On Saturday, September 12, 2015 05:55:41 pm Salz, Rich wrote:
> > > After all, what are you going to do when the connection drops 
> > > without a GOAWAY?  Drop the connection?
> > 
> > Try again, assuming the problem is a one-time glitch?
> 
> That's important.  Without the alert, you might just try again.  And again.  
> And again.. ..

On Saturday, September 12, 2015 06:18:46 pm Viktor Dukhovni wrote:
> Interoperability problems are hard enough to debug even when alerts 
> are sent, and they are *very* useful.  If the peer just hangs up, we 
> don't know whether it crashed, refused service, enforced some protocol 
> or policy constraint, ...

To reiterate in this thread, not being strict with error alert requirements is 
how we got TLS version intolerance, which is how we got insecure fallback. This 
one instance is sufficient for me to say that almost all alerts specified for 
during the handshake should be mandatory. Allowing fuzzy reactions to errors on 
one end leads to fuzzy kludges to deal with them on the other. We should 
attempt to map out every possible logic path and at least have an expectation 
given, if not mandated. People are less likely to do stupid things in their 
implementations if they're actually told what they're dealing with properly.


Dave

___
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

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

[Salz, Rich]

> > After all, what are you going to do when the connection drops without
> > a GOAWAY?  Drop the connection?
> 
> Try again, assuming the problem is a one-time glitch?

That's important.  Without the alert, you might just try again.  And again.  
And again.. ..

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

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

[Eric Rescorla]

On Sat, Sep 12, 2015 at 2:13 PM, Martin Thomson 
wrote:

> On 12 September 2015 at 13:49, Eric Rescorla  wrote:
> > "Nobody must ever be required to send an alert. Any requirement for
> sending
> > an alert should be SHOULD, at most."
>
> This was a point of debate for HTTP/2 as well.  The conclusion there
> was that you had to be prepared to have the connection disappear
> without warning for various reasons, so requiring that an error be
> sent was silly.
>
> After all, what are you going to do when the connection drops without
> a GOAWAY?  Drop the connection?
>
> That only applies to fatal alerts of course, but I don't see a lot of
> use of the warning level, in fact, they might be a bad thing to
> support (but that's a separate subject).  My suggestion is that we
> require that endpoints treat certain errors as fatal and maybe suggest
> a particular alert.  However, also note that they MAY drop the
> connection without sending the alert OR that even if they do send the
> alert, it might get lost.
>

It seems like there are the following options:

1. Require termination and say nothing else
2. Require termination and suggest an alert.
3. Require termination and say that if you send an alert it must be X.
4. Require termination and say that you must send alert X.


As you say, implementations can always terminate without sending
alerts, however (at least in TLS 1.2) alerts served three purposes:

1. A secure indication of close (and for orderly close in the case
of close_notify).
2. Session cache invalidation.
3. An indication to the other side of what went wrong.

At least in the third cases, even if implementations can in principle
close without sending alerts, they still serve a function and one might
argue that that's a reason to encourage/require them.

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

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

[Geoffrey Keating]

Martin Thomson  writes:

> On 12 September 2015 at 13:49, Eric Rescorla  wrote:
> > "Nobody must ever be required to send an alert. Any requirement for sending
> > an alert should be SHOULD, at most."
> 
> This was a point of debate for HTTP/2 as well.  The conclusion there
> was that you had to be prepared to have the connection disappear
> without warning for various reasons, so requiring that an error be
> sent was silly.
> 
> After all, what are you going to do when the connection drops without
> a GOAWAY?  Drop the connection?

Try again, assuming the problem is a one-time glitch?

> That only applies to fatal alerts of course, but I don't see a lot of
> use of the warning level, in fact, they might be a bad thing to
> support (but that's a separate subject).  My suggestion is that we
> require that endpoints treat certain errors as fatal and maybe suggest
> a particular alert.  However, also note that they MAY drop the
> connection without sending the alert OR that even if they do send the
> alert, it might get lost.

For a lot of the alerts, two correct implementations speaking to each
other should never use them, so it's hard to standardise what to do about them.

However I would suggest that the unsupported_certificate, unknown_ca,
protocol_version or insufficient_security alerts, benefit
interoperability because the server (or client in some cases) might be
able to do something different in the negotation if it is retried (for
example present a different certificate chain), but only if it knows
what the problem was.  So I'd suggest these should be MUST.

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

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

[Martin Thomson]

This seems like the right set of options...

On 12 September 2015 at 14:26, Eric Rescorla  wrote:
> 1. Require termination and say nothing else

I think the mere existence of alerts suggests that this isn't really a
good option.

> 2. Require termination and suggest an alert.
> 3. Require termination and say that if you send an alert it must be X.

I think that the distinction between these relies on the suggestion
that we think that lying about causes would be desirable in some
cases.  I think that the latter would be better.

> 4. Require termination and say that you must send alert X.

As Geoff indicates, maybe this makes sense in cases where the
information the alert carries is especially valuable.  I can accept
that argument.

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

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

[Eric Rescorla]

On Sat, Sep 12, 2015 at 3:18 PM, Viktor Dukhovni 
wrote:

> On Sat, Sep 12, 2015 at 01:49:49PM -0700, Eric Rescorla wrote:
>
> > "Nobody must ever be *required* to send an alert. Any requirement for
> > sending an alert should be SHOULD, at most."
>

To be clear, you're quoting me quoting Brian Smith. This isn't my position.



> Interoperability problems are hard enough to debug even when alerts
> are sent, and they are *very* useful.  If the peer just hangs up,
> we don't know whether it crashed, refused service, enforced some
> protocol or policy constraint, ...
>
> I help many users debug TLS connectivity issues, and would be
> considerably hampered in this without alert information.
>
> --
> Viktor.
>
> ___
> 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

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

[Viktor Dukhovni]

On Sat, Sep 12, 2015 at 01:49:49PM -0700, Eric Rescorla wrote:

> "Nobody must ever be *required* to send an alert. Any requirement for
> sending an alert should be SHOULD, at most."

Interoperability problems are hard enough to debug even when alerts
are sent, and they are *very* useful.  If the peer just hangs up,
we don't know whether it crashed, refused service, enforced some
protocol or policy constraint, ...

I help many users debug TLS connectivity issues, and would be
considerably hampered in this without alert information.

-- 
Viktor.

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