Subject: Re: [TLS] Expanded alert codes

From: Peter Gutmann <[email-masked]>
Date: Mon, 21 May 2018 12:09:28 +0000

Reviving this discussion, if I write up a draft for this what's going to
happen to it?  Will it get published, or shouted down?  The reason I'm asking
is that I've just spent the past three days debugging a TLS issue that's
pretty much a poster child for why extended alerts are needed, it was
something that would have been resolved in a single handshake exchange with
extended alerts, but took three days to sort out without them.  The sequence
was as follows:

  Client sends standard client hello.
  Server responds with handshake failed alert.

The same client has been running for years, and connects fine to any number of
servers, and openssl and some web browsers connect fine to the server.  The
only message exchanged was the hello, so there's zero security issues in
providing extended alerts.

Since some people have argued that extended alerts aren't necessary or useful,
I'll wait awhile for them to diagnose what was wrong using the information
above, which was all that was available.

Peter.

---

From: Ion Larranaga Azcue <[email-masked]>
Date: Mon, 21 May 2018 13:47:37 +0000

I would say it's unfair to expect other people to diagnose the problem by claiming "that information was all that was available" because you had access to:

- traffic dumps of the failing handshakes
- traffic dumps of working handshakes
- the possibility to try any number of modifications of the client hello to go from a working handshake to a failing handshake in order to identify the offending option or parameter
- as you are going to have to ask the server side to activate extended alerts, you can ask them for server logs, as well as traffic dumps of (at least) the failed connections on their side (if they receive any, which is additional information)

Besides, I also think it's not fair to claim that when someone disagrees, you are being "shouted down". From what I remember, both sides expressed their opinion, and if you manage to gather consensus your draft will get published. So, I think accusing others of shouting you down is an unfortunate phrase on your side...

That being said... I encourage you to write your draft and look for consensus within the group.

Regards,

   Ion

-----Mensaje original-----
De: TLS [mailto:[email-masked]] En nombre de Peter Gutmann
Enviado el: lunes, 21 de mayo de 2018 14:09
Para: Eric Rescorla <[email-masked]>
CC: Dale R. Worley <[email-masked]>; <[email-masked]> <[email-masked]>
Asunto: Re: [TLS] Expanded alert codes

Reviving this discussion, if I write up a draft for this what's going to happen to it?  Will it get published, or shouted down?  The reason I'm asking is that I've just spent the past three days debugging a TLS issue that's pretty much a poster child for why extended alerts are needed, it was something that would have been resolved in a single handshake exchange with extended alerts, but took three days to sort out without them.  The sequence was as follows:

The same client has been running for years, and connects fine to any number of servers, and openssl and some web browsers connect fine to the server.  The only message exchanged was the hello, so there's zero security issues in providing extended alerts.

Since some people have argued that extended alerts aren't necessary or useful, I'll wait awhile for them to diagnose what was wrong using the information above, which was all that was available.

Peter.

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 22 May 2018 02:16:53 +0000

Ion Larranaga Azcue <[email-masked]> writes:

>I would say it's unfair to expect other people to diagnose the problem by
>claiming "that information was all that was available" because you had access
>to:
>

There was no access to this.

>- traffic dumps of working handshakes

There was no access to this.

>- the possibility to try any number of modifications of the client hello to
>go from a working handshake to a failing handshake in order to identify the
>offending option or parameter

That was only after the second day of negotiations, when I managed to get
indirect access to the server to use it as an oracle, resulting in trial-and-
error modification of the client hello until the server didn't report a
handshake failure any more.

>- as you are going to have to ask the server side to activate extended
>alerts, you can ask them for server logs, as well as traffic dumps of (at
>least) the failed connections on their side (if they receive any, which is
>additional information)

Neither of those were available, and neither of them could be made available.
As I said in my previous message, the only information I had was "Handshake
failed".

>Besides, I also think it's not fair to claim that when someone disagrees, you
>are being "shouted down". 

What I meant was that as it's a non-zero amount of effort to write up a draft,
I wasn't terribly keen on putting in the effort only to have it bikeshedded to
death with "it's a security problem" (it isn't, unless you go out of your way
to make it one), "you can look at the server logs" (no, you can't), etc.  So
what I was trying to get is an idea of whether it's worth writing a draft or
not.

>That being said... I encourage you to write your draft and look for consensus

OK, I'll give it a go.

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Tue, 22 May 2018 15:11:43 +0200

On Monday, 21 May 2018 15:47:37 CEST Ion Larranaga Azcue wrote:
> claiming "that information was all that was available" because you had
> access to:
> 
> offending option or parameter - as you are going to have to ask the server
> side to activate extended alerts, you can ask them for server logs, as well
> as traffic dumps of (at least) the failed connections on their side (if
> they receive any, which is additional information)
> 
> Besides, I also think it's not fair to claim that when someone disagrees,
> you are being "shouted down". From what I remember, both sides expressed
> their opinion, and if you manage to gather consensus your draft will get
> published. So, I think accusing others of shouting you down is an
> unfortunate phrase on your side...

you need consensus for Informational RFCs? that's news to me...
 
> consensus within the group.

For what it's worth, and with all the downsides it would have (it would have 
to be an extension, so not every server would implement it; what about alerts 
not allowed to be fragmented, and interaction with max_fragment_length?), I'm 
in favour of more expressive errors (and more strict/detailed guidelines which 
ones should be sent when).

> happen to it?  Will it get published, or shouted down?  The reason I'm
> asking is that I've just spent the past three days debugging a TLS issue
> that's pretty much a poster child for why extended alerts are needed, it
> was something that would have been resolved in a single handshake exchange
> with extended alerts, but took three days to sort out without them.  The
> sequence was as follows:
> 
> The same client has been running for years, and connects fine to any number
> of servers, and openssl and some web browsers connect fine to the server. 
> The only message exchanged was the hello, so there's zero security issues
> in providing extended alerts.
> 
> Since some people have argued that extended alerts aren't necessary or
> useful, I'll wait awhile for them to diagnose what was wrong using the
> information above, which was all that was available.
> 
> Peter.
> 

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 May 2018 06:22:10 -0700

> you need consensus for Informational RFCs? that's news to me...

You need consensus for WG documents in general, though not necessarily for
Informational RFCs through other channels.

With that said, once
https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ is
published, it will not be necessary to have an RFC at all for a code point
registration.

-Ekr