Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Stan Kalisch]

> On Apr 7, 2018, at 8:37 PM, Peter Gutmann  wrote:
> 
> I can't believe the amount of pointless bikeshedding that's already been done 
> over something that's going to be a rarely-if-ever used mechanism for one set
> of hardcore technical developers to communicate to another set of hardcore 
> technical developers.

Not to be too Steve Jobs about it, but I was simply trying to have a little 
imagination and question assumptions (including my own) about how the size of 
the developer base could grow, and what that could mean.  So if being 
thoughtful to the point where one has the occasional slight digression is 
bikeshedding, that's fine with me.

> This isn't a design for a multilingual IM system with emojis and animated 
> GIFs,

Thank you for clearing that up.

> it's a rarely-used debugging/diagnostic facility,
> and yet we're arguing over whether a developer who can read a lengthy
> technical document specified entirely in US-ASCII (TLS RFC) and implement it 
> in C or Java (US-ASCII, English keywords) will be unable to communicate an 
> error message in anything but Cantonese (or Mandarin, or Qiang, or Kam–Sui, or
> Kipchak, or whatever was meant by "Chinese").

Actually, no, we're not arguing over that.

> Even for the few steps in the process where there's i18n available like the 
> gcc compile stage, the Chinese-speaking devs I know use the English version 
> because they don't want an attempted guess in another language at what the
> error is,

And because they also know English.


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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Ion Larranaga Azcue]

I think you don't really get my position in this issue... No, I'm not going to 
start a list of numeric codes because I don't believe in this functionality. 
Not even numeric extended alert codes have any appeal to me, it's just the 
least offending idea.

In my opinion, someone wants this functionality because he doesn't want to ask 
the server administrators to analyze or even send the debug logs in the peer 
side, which already have the information he needs. He is trying to substitute a 
person-to-person interaction he doesn't want to perform for a 
computer-to-computer interaction he sees as more convenient. Maybe without 
realizing he still needs to ask peer administrators to enable this debug 
functionality on a (most likely) production server.

So, I'm totally against this whole idea but if everybody else supports it, I'm 
going to try to do damage control and suggest limiting the amount of 
information that can (will) be leaked.

-Mensaje original-
De: Peter Gutmann [mailto:pgut...@cs.auckland.ac.nz] 
Enviado el: lunes, 9 de abril de 2018 11:50
Para: Ion Larranaga Azcue <ila...@s21sec.com>
CC: tls@ietf.org
Asunto: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

Ion Larranaga Azcue <ila...@s21sec.com> writes:

>I don't think it's necessary going to that degree of detail. For your 
>specific first example, alert the alert "bad_certificate" is enough

We already have error codes at about that level.  They're not enough to debug 
any problems (I mean, "bad certificate" is only marginally better than the 
canonical Ken Thompson Unix error message in which a giant "?" lights up in 
front of you, "the experienced TLS developer will usually know what's wrong"), 
thus the need for free-form text messages that tell you what the actual problem 
is.

>The problem I see with it is that it's hard for applications to 
>automatically parse it,

Applications don't need to parse it, it's an optional, opt-in 
debugging/diagnostic facility to help developers sort out why a handshake is 
failing, not something that an application is meant to process.

>I would first start trying to define an extended error reporting 
>protocol using only numeric codes

Please, go ahead and do so.  For that we'll probably need to start a new list 
to allow everyone to debate at length which error codes are needed and what 
they should represent.  tls-error-bikeshedd...@ietf.org seems to be a good 
candidate name.

Either that or say it's a UTF-8 string with free-form text, and we'll assume 
developers can somehow manage to figure the rest out themselves, as they have 
for pretty much every other situation in which free-form text error messages 
are used.

Peter.

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Peter Gutmann]

Ion Larranaga Azcue  writes:

>I don't think it's necessary going to that degree of detail. For your
>specific first example, alert the alert "bad_certificate" is enough

We already have error codes at about that level.  They're not enough to debug
any problems (I mean, "bad certificate" is only marginally better than the
canonical Ken Thompson Unix error message in which a giant "?" lights up in
front of you, "the experienced TLS developer will usually know what's wrong"),
thus the need for free-form text messages that tell you what the actual
problem is.

>The problem I see with it is that it's hard for applications to automatically
>parse it,

Applications don't need to parse it, it's an optional, opt-in
debugging/diagnostic facility to help developers sort out why a handshake is
failing, not something that an application is meant to process.

>I would first start trying to define an extended error reporting protocol
>using only numeric codes

Please, go ahead and do so.  For that we'll probably need to start a new list
to allow everyone to debate at length which error codes are needed and what
they should represent.  tls-error-bikeshedd...@ietf.org seems to be a good
candidate name.

Either that or say it's a UTF-8 string with free-form text, and we'll assume
developers can somehow manage to figure the rest out themselves, as they have
for pretty much every other situation in which free-form text error messages
are used.

Peter.

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Peter Gutmann]

Stan Kalisch  writes:

>On Fri, Apr 6, 2018, at 3:54 PM, Ion Larranaga Azcue wrote:
>>
>> My opinion is that if we are going to have extended error codes, it's
>> better to use numeric ones and not text based errors.
>
>That was my own gut feeling on the least painful way to go, but I'm open to
>the possibility that gut feeling was woefully naive.

To see why this won't work, you just need to think one step further: Try
sitting down and defining the numeric error codes you're proposing.

If it's still not obvious: The reason why we need free-form strings is because
the numeric codes we already have provide insufficient detail.  To provide the
required detail, you'd need to define numeric codes for every error condition
and failed check that every TLS and PKI library (because lots of handshake
failures are due to problems with certs) could wish to communicate.  To take a
PKI example, there's "Certificate chain with length %d has a path constraint
of length %d", which for reasonable values of the two %d leads to, say, around
a hundred error codes just for that one condition.  Then take every single
type of error that would need to be communicated and you're into at least 16-
bit values, or 32- or 64-bit if you take cases like "Packet length of %d
indicated but only %d bytes were sent".

Even if someone came up with the massive codebook of thousands or tens of
thousands of error codes, which TLS author would want to spend hours paging
through them to find the right code for each situation?

Conversely, if you limit the number of error codes to, say, 5,000, how are you
going to convince TLS library authors to check for and report only those
errors?  What happens if new error types are defined?

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Viktor Dukhovni]

> On Apr 6, 2018, at 7:39 PM, Eric Rescorla  wrote:
> 
> That would depend on how you designed the feature. Because the client would 
> have
> to opt-in in any case, it could provide its locale in that opt-in message.
> 
> I'm not saying that this (or even the feature at all) is necessarily a good 
> idea, but
> it's not like it's impossible.

Yes, it is not impossible, but it is much too brittle.  There's little reason 
(in general)
to expect the server to have support for the client's locale, let alone have 
locale-specific
translation tables for TLS errors.  Numeric codes are much better if the error 
reasons are
easily to classify in advance. Otherwise, numeric codes + UTF8 text in English.

This works with enhanced status codes in SMTP, which some MUAs (Outlook) render 
in local
languages based on the status code, but the remote postmaster will want the 
original text,
so that's often more useful for debugging when there's a problem (and not just 
a wrong
email address).

-- 
Viktor.

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Eric Rescorla]

On Fri, Apr 6, 2018 at 4:11 PM, Viktor Dukhovni 
wrote:

> On Fri, Apr 06, 2018 at 12:10:35PM +, Salz, Rich wrote:
>
> > >For debugging messages, I'm with Peter, they'll only be implemented
> if they're
> > >   simple enough to support.  I can't see having to have localization
> files on the
> > >   server for debug messages that might be requested by a client is
> some other locale
> > >   and only when debug is enabled, and the consumer is a developer and
> not an end-user.
> >
> > The table stakes have increased, and I don't think it is reasonable any
> > more for any IETF protocol to have "just use ASCII" for text messages.
> > It could be UTF8, or it could be codeset/tagged.  Why two developers in,
> > say, Russia need to speak English to debug their TLS implementations.
>
> Because the server has no idea what locale the client is in.
> Localization is not an option.


That would depend on how you designed the feature. Because the client would
have
to opt-in in any case, it could provide its locale in that opt-in message.

I'm not saying that this (or even the feature at all) is necessarily a good
idea, but
it's not like it's impossible.

-Ekr


The only option (which is essentially
> "use-ascii") is to use UTF-8, and then the error messages are in
> whatever language the developer of the server used.  So the Russian
> developer will be seeing Chinese debug messages from the server.
> That's not progress.
>
> If you want localization, the messages need to be numeric codes,
> with localized string tables on each client.  But then older clients
> might not understand some new server messages (perhaps OK if the
> message list is sufficiently stable given a client protocol version
> and set of client supported extensions).
>
> --
> 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] Genart last call review of draft-ietf-tls-tls13-24

[Stan Kalisch]

On Fri, Apr 6, 2018, at 3:54 PM, Ion Larranaga Azcue wrote:
> My opinion is that if we are going to have extended error codes, it's
> better to use numeric ones and not text based errors.
That was my own gut feeling on the least painful way to go, but I'm open
to the possibility that gut feeling was woefully naive.

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Viktor Dukhovni]

On Fri, Apr 06, 2018 at 12:10:35PM +, Salz, Rich wrote:

> >For debugging messages, I'm with Peter, they'll only be implemented if 
> > they're
> >   simple enough to support.  I can't see having to have localization files 
> > on the
> >   server for debug messages that might be requested by a client is some 
> > other locale
> >   and only when debug is enabled, and the consumer is a developer and not 
> > an end-user.
>
> The table stakes have increased, and I don't think it is reasonable any
> more for any IETF protocol to have "just use ASCII" for text messages.
> It could be UTF8, or it could be codeset/tagged.  Why two developers in,
> say, Russia need to speak English to debug their TLS implementations.

Because the server has no idea what locale the client is in.
Localization is not an option.  The only option (which is essentially
"use-ascii") is to use UTF-8, and then the error messages are in
whatever language the developer of the server used.  So the Russian
developer will be seeing Chinese debug messages from the server.
That's not progress.

If you want localization, the messages need to be numeric codes,
with localized string tables on each client.  But then older clients
might not understand some new server messages (perhaps OK if the
message list is sufficiently stable given a client protocol version
and set of client supported extensions).

-- 
Viktor.

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Ion Larranaga Azcue]

Hi,


My opinion is that if we are going to have extended error codes, it's better to 
use numeric ones and not text based errors. Imagine a chinese client trying to 
troubleshoot a connection to a server using a TLS stack that reports its errors 
in russian. That would be crazy!


I'm not saying that forcing English is better. There are many people out there 
who have problems with english as well, and I'm sure that they would rather 
look a numeric code in a table with localized error messages than having to use 
google translate.


That being said...


If in the end a decission is made to have text based error messages, I think 
that the messages should be (at least) UTF-8. If a developer wants to generate 
an error message including information from the certificate (I can't imagine a 
valid scenario but... why not?), there are many places where UTF-8 is allowed. 
Additionally, a server name can also contain non-ASCII characters and so on...



De: TLS <tls-boun...@ietf.org> en nombre de Stan Kalisch 
<s...@glyphein.mailforce.net>
Enviado: viernes, 6 de abril de 2018 16:39
Para: tls@ietf.org
Asunto: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

Hi,

On Fri, Apr 6, 2018, at 8:10 AM, Salz, Rich wrote:
The table stakes have increased,

Exactly.

and I don't think it is reasonable any more for any IETF protocol to have "just 
use ASCII" for text messages.  It could be UTF8, or it could be codeset/tagged. 
 Why two developers in, say, Russia need to speak English to debug their TLS 
implementations.

Viktor rightly points out that in this situation the developer is the consumer. 
 As the Internet exponentially expands-often in ways we're not always able to 
posit ahead of time-the base of developers exponentially expands.  The IETF 
shouldn't be sanguine about the possibility that at some point the number of 
those developers who do not speak English will reach a critical mass that is 
able to start eschewing protocols that it finds too mired in US-ASCII.

I would ask anybody who would say it could never happen how sure they are of 
that assertion.


Thanks,
Stan

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Stan Kalisch]

Hi,

On Fri, Apr 6, 2018, at 8:10 AM, Salz, Rich wrote:
> The table stakes have increased,

Exactly.

> and I don't think it is reasonable any more for any IETF protocol to
> have "just use ASCII" for text messages.  It could be UTF8, or it
> could be codeset/tagged.  Why two developers in, say, Russia need to
> speak English to debug their TLS implementations.
Viktor rightly points out that in this situation the developer is the
consumer.  As the Internet exponentially expands—often in ways we're not
always able to posit ahead of time—the base of developers exponentially
expands.  The IETF shouldn't be sanguine about the possibility that at
some point the number of those developers who do not speak English will
reach a critical mass that is able to start eschewing protocols that it
finds too mired in US-ASCII.
I would ask anybody who would say it could never happen how sure they
are of that assertion.

Thanks,
Stan

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Viktor Dukhovni]

> On Apr 1, 2018, at 10:37 AM, Salz, Rich  wrote:
> 
>>   Possibly, if you consider being able to say "Invalid length encoding in
>preferred-ECC-curves extension" in Tswana is mission-critical to debugging 
> a
>TLS handshake failure.
> 
> I so love your messages, Peter.  Honestly I do.
> 
> Perhaps not Tswana, but perhaps China may care to pick a counter-example.

For debugging messages, I'm with Peter, they'll only be implemented if they're
simple enough to support.  I can't see having to have localization files on the
server for debug messages that might be requested by a client is some other 
locale
and only when debug is enabled, and the consumer is a developer and not an 
end-user.

-- 
Viktor.

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Dale R. Worley]

Bill Frantz  writes:
> We have always avoided the long form error messages in TLS 
> because they can be of great help to attackers as well as 
> debuggers. I think this objection is much weaker if we write the 
> long form error messages into a log that is kept with other 
> server logs.

I'd not considered textual messages.  What struck me is that the draft
has dozens, maybe more than 100, conditions that must be satisfied, and
only a few different error codes.  It strikes me that each particular
rule could be assigned an error number, so an implementation could point
out which of the dozens of rules was violated in a particular handshake.

Dale

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Salz, Rich]

>Possibly, if you consider being able to say "Invalid length encoding in
preferred-ECC-curves extension" in Tswana is mission-critical to debugging a
TLS handshake failure.
  
I so love your messages, Peter.  Honestly I do.

Perhaps not Tswana, but perhaps China may care to pick a counter-example.


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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Peter Gutmann]

Salz, Rich  writes:

>>format, which I assume just means adding a free-form text field to the
>>existing alerts.
> 
>Doesn't it have to be tagged with language and codeset these days?

Possibly, if you consider being able to say "Invalid length encoding in
preferred-ECC-curves extension" in Tswana is mission-critical to debugging a
TLS handshake failure.

>I think we're past USASCII 

Since this is being used purely as a debugging facility by one set of
developers to communicate technical details to another set of developers, I'd
say it should use the same language and terminology that the technical spec
that's being implemented is written in.  Let me just check for a second what
that could be.

Gosh, it's USASCII.

Peter.

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Salz, Rich]

>format, which I assume just means adding a free-form text field to the
existing alerts.
  
Doesn't it have to be tagged with language and codeset these days?  I think 
we're past USASCII ...


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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Peter Gutmann]

Kathleen Moriarty  writes:

>I agree with Eric’s assessment, this could be in a new draft as an extension. 

Anyone want to work on this?  I can contribute a bit by recycling the EtM
text, which sets out how to communicate a boolean flag (for "I speak extended
alerts") as an extension, apart from that you just need to define the alert
format, which I assume just means adding a free-form text field to the
existing alerts.

Peter.

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Kathleen Moriarty]

Sent from my mobile device

> On Mar 30, 2018, at 5:20 PM, Eric Rescorla  wrote:
> 
> Hi folks,
> 
> TLS 1.3 has been approved by the IESG and it's on its way to the RFC Editor, 
> so 
> I don't really see this changing any time soon for the base RFC.
> 
> I think there's some debate about whether this is a good idea, but in any 
> case,
> the right way to pursue it would be to publish a new draft, presumably with
> some extension that says "I speak extended alerts".
> 
I agree with Eric’s assessment, this could be in a new draft as an extension.

Kathleen 

> -Ekr
> 
> 
> 
> 
>> On Fri, Mar 30, 2018 at 1:55 PM, Bill Frantz  wrote:
>> On 3/30/18 at 7:35 PM, pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote:
>> 
>>> As you mention, debugging TLS is unnecessarily painful if there's a problem,
>>> you typically just get a handshake-failed alert which is essentially no
>>> information at all.  Having a debug-mode capability to send back a long-form
>>> error message would be extremely useful, maybe an extension to say "send 
>>> back
>>> a long-form alert with more than just 'BOOLEAN succeeded = FALSE' in it"
> 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Peter Gutmann]

Bill Frantz  writes:

>We have always avoided the long form error messages in TLS because they can
>be of great help to attackers as well as debuggers. 

That's why I said it was a debug-only capability, not an always-enabled on-by-
default capability.

>I think this objection is much weaker if we write the long form error
>messages into a log that is kept with other server logs.

That's the worst-case debugging scenario I mentioned where you need to contact
the server admin on every test run to see what went wrong.  What you've
described is the (broken) status quo that people in this thread are trying to 
fix.

Peter.

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Eric Rescorla]

Hi folks,

TLS 1.3 has been approved by the IESG and it's on its way to the RFC
Editor, so
I don't really see this changing any time soon for the base RFC.

I think there's some debate about whether this is a good idea, but in any
case,
the right way to pursue it would be to publish a new draft, presumably with
some extension that says "I speak extended alerts".

-Ekr




On Fri, Mar 30, 2018 at 1:55 PM, Bill Frantz  wrote:

> On 3/30/18 at 7:35 PM, pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote:
>
> As you mention, debugging TLS is unnecessarily painful if there's a
>> problem,
>> you typically just get a handshake-failed alert which is essentially no
>> information at all.  Having a debug-mode capability to send back a
>> long-form
>> error message would be extremely useful, maybe an extension to say "send
>> back
>> a long-form alert with more than just 'BOOLEAN succeeded = FALSE' in it"
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Bill Frantz]

On 3/30/18 at 7:35 PM, pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote:


As you mention, debugging TLS is unnecessarily painful if there's a problem,
you typically just get a handshake-failed alert which is essentially no
information at all.  Having a debug-mode capability to send back a long-form
error message would be extremely useful, maybe an extension to say "send back
a long-form alert with more than just 'BOOLEAN succeeded = FALSE' in it".


We have always avoided the long form error messages in TLS 
because they can be of great help to attackers as well as 
debuggers. I think this objection is much weaker if we write the 
long form error messages into a log that is kept with other 
server logs.


Cheers - Bill

---
Bill Frantz| Ham radio contesting is a| Periwinkle
(408)356-8506  | contact sport.   | 16345 
Englewood Ave
www.pwpconsult.com |  - Ken Widelitz K6LA / VY2TT | Los Gatos, 
CA 95032


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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Peter Gutmann]

Steve Fenter  writes:

>I've done a fair amount of TLS handshake troubleshooting, and it's usually
>long and painful because the error codes are so vague. 
>[...]
>The vague error messages are leading directly to more downtime, and this
>should be balanced with the other security needs. 

This was the reason for the sole new feature that was added to SCEP, an
optional text-form error message to explain why you didn't get a certificate.
Prior to that it was pure guesswork, there was just a generic error code
saying "you didn't get your cert", which made things almost impossible to
debug if you didn't have someone you could phone at the CA who could tell you
why you didn't get your cert.

As you mention, debugging TLS is unnecessarily painful if there's a problem,
you typically just get a handshake-failed alert which is essentially no
information at all.  Having a debug-mode capability to send back a long-form
error message would be extremely useful, maybe an extension to say "send back
a long-form alert with more than just 'BOOLEAN succeeded = FALSE' in it".

Peter.

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Steve Fenter]

I'd like to echo Dale's sentiments on the error codes.  I've done a fair amount 
of TLS handshake troubleshooting, and it's usually long and painful because the 
error codes are so vague. Another factor in debugging is that people 
troubleshooting TLS in the enterprise are typically not the same level of 
experts as those who are writing TLS code.  The TLS working group folks seem to 
have their fingers in TLS every day and know it backwards and forwards, so 
debugging a problem is not so difficult for them. They can also read code to 
figure out what is going on. In contrast, I see a TLS handshake problem once 
every few months.  The rest of the time I'm looking at HTTP, SQL, SMB, or 
whatever. So enterprise troubleshooters are not going to be as deep in their 
understanding of TLS by the nature of their jobs, and they need all the help 
they can get (like from descriptive error messages).  The vague error messages 
are leading directly to more downtime, and this should be balanced with the 
other security needs. I'm not saying this needs to be fixed immediately, but it 
should be considered somewhere down the road.

> On Mar 6, 2018, at 9:35 PM, wor...@ariadne.com (Dale R. Worley) wrote:
> 
> Colm MacCárthaigh  writes:
>> On the specific suggestion of having more granular error codes, I think
>> this is a dangerous direction to take lightly; there's at least one
>> instance where granular TLS alert messages have directly led to security
>> issues by acting as oracles that aided the attacker.
>> 
>> There's a general conjecture that the more information that is provided to
>> attackers, the more easily they can leverage into a compromise. Personally
>> I believe that conjecture, and would actually prefer to see fewer signals,
>> ideally as few as one big error code. There is a trade-off against
>> debugability, but I've only seen a handful of people have the skills to
>> debug low level TLS issues and it doesn't seem worth the risk. Others
>> disagree, which is valid, but it's at least an area of reasonable
>> contention.
> 
> I believe I've heard that position stated before, and I give it
> credibility.  I retreat to the statement I made at the top of my review,
> that I'm not experienced in security.  OTOH, I've spent a lot of the
> previous couple of decades debugging SIP call flows, so I've learned to
> appreciate any aid to debuggability that exists.
> 
> I'm tempted to consider this a classic case of conflicting requirements,
> and ask if our cryptographic experience can help us square this circle.
> 
> Dale
> 
> ___
> 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] Genart last call review of draft-ietf-tls-tls13-24

[David Benjamin]

+1. If anything, the existing "buggy implementation" alert codes should get
folded together. (But I don't think it's worth making that change at this
stage either.) E.g. decode_error vs illegal_parameter vs
unexpected_message are rather useless distinctions and trying to get them
"right" adds complexity. Even with the granularity is it is, TLS's alert
codes needlessly expose benign differences in implementation strategy.
Adding even finer granularity would make all this worse.

My experience is also that this sort of thing would not actually help much.

On Tue, Mar 6, 2018 at 11:05 PM Eric Rescorla  wrote:

> Without taking a position on the security matter: this has been part of
> the TLS design for 20+ years, and therefore has had multiple LCs and WG and
> IETF consensus, so it would take a pretty strong set of arguments to change
> now. I've debugged a lot of TLS interop issues, and as a practical matter,
> I don't think this would help that much to justify making a change.
> -Ekr
>
>
> On Tue, Mar 6, 2018 at 2:35 PM, Colm MacCárthaigh 
> wrote:
>
>>
>>
>> On Fri, Mar 2, 2018 at 8:00 PM, Dale Worley  wrote:
>>
>>> - There are about 28 error codes but nearly 150 places where the text
>>>   require the connection to be aborted with an error -- and hence,
>>>   nearly 150 distinct constraints that can be violated.  There are 19
>>>   alone for "illegal_parameter".  I would like to see an "alert
>>>   extension value" which assigns a distinct "minor" code to each
>>>   statement in the text that requires an error response (with
>>>   implementations being allowed to be a bit sloppy in providing the
>>>   correct minor code).
>>>
>>
>> Your review is incredibly deep, comprehensive and I learned a lot from
>> it. I want to pick out just one small piece, but don't mean that to
>> diminish how thorough it was!
>>
>> On the specific suggestion of having more granular error codes, I think
>> this is a dangerous direction to take lightly; there's at least one
>> instance where granular TLS alert messages have directly led to security
>> issues by acting as oracles that aided the attacker.
>>
>> There's a general conjecture that the more information that is provided
>> to attackers, the more easily they can leverage into a compromise.
>> Personally I believe that conjecture, and would actually prefer to see
>> fewer signals, ideally as few as one big error code. There is a trade-off
>> against debugability, but I've only seen a handful of people have the
>> skills to debug low level TLS issues and it doesn't seem worth the risk.
>> Others disagree, which is valid, but it's at least an area of reasonable
>> contention.
>>
>> --
>> Colm
>>
>
> ___
> 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

[TLS] Genart last call review of draft-ietf-tls-tls13-24

[Dale Worley]

Reviewer: Dale Worley
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document:  draft-ietf-tls-tls13-24
Reviewer:  Dale R. Worley
Review Date:  2018-03-02
IETF LC End Date:  2018-03-02
IESG Telechat date:  2018-03-08

Summary:

   This draft is basically ready for publication, but has nits
   that should be fixed before publication.

This review only covers the general properties of the proposed
protocol and the exposition, as I am unqualified to assess its
security properties.

There are various places where the exposition could be made clearer,
especially to readers not immersed in security matters.  In many
places, it is mostly a matter of making clearer the connections
between different points in the exposition.

In a few places, there seems to be ambiguity regarding the
specification that has technical significance.  In particular:

- There is inexactness about "transcript", "handshake context", and
  "context".

- When a server receives ClientHello, is it obligated to promptly send
  not just the ServerHello, but all first-flight messages from
  ServerHello through Finished?  (section 4.2.11.3)  I ask this
  because the client is only obligated/permitted to send
  EndOfEarlyData when it receives the server's Finished.

- It seems inconsistent that the client can send an empty Certificate
  message, but the server cannot, even though the server can omit
  sending the Certificate message.  (section 4.4.2.4)

- Comparing sections 4.2.10 and 4.6.1, when a PSK was established in
  an earlier connection, exactly what are the limitations on the
  cryptographic parameters that can be used when the PSK is used in a
  resumption connection?  4.2.10 suggests that the following must be
  the same in both connections:  TLS version, cipher suite, ALPN.  But
  4.6.1 suggests that different cipher suites can be used, as long as
  they use the same hash algorithm.

- In regard to section 4.6.1, it seems to require that a client MAY
  NOT resume a connection using a ticket issued during a connection in
  which the server did not present a certificate for itself, because
  in the handshake of the resumption connection, the client is required
  to verify that the SNI is compatible with the certificate the server
  presented in the original connection.  But that constraint isn't
  stated in section 2.2, despite being a global constraint on the
  structure of sessions.

- Presumably implementations MUST NOT send zero-length fragments of alert
  messages for the same reasons that they cannot send zero-length
  fragments of handshake messages (whatever those reasons are).

- There are about 28 error codes but nearly 150 places where the text
  require the connection to be aborted with an error -- and hence,
  nearly 150 distinct constraints that can be violated.  There are 19
  alone for "illegal_parameter".  I would like to see an "alert
  extension value" which assigns a distinct "minor" code to each
  statement in the text that requires an error response (with
  implementations being allowed to be a bit sloppy in providing the
  correct minor code).

- I take it that there is no "close read side" operation.  (If that
  existed, TLS could generate the "broken pipe" error.)

There are a number of issues which span the whole text:

The interaction of this draft with extensions defined for previous
versions of TLS is not laid out clearly.  It seems safe enough for
this draft to import data structures from earlier extensions with only
a reference to the earlier RFC, but if an extension defines behavior
(e.g., a negotiation process), exactly what is the specification of
that behavior in TLS 1.3, given that the referenced RFC only defines
its use in TLS 1.2 or earlier?  At the least, there should be an
explicit statement that the behaviors are carried forward in the
"obvious way".

It's also not clear exactly which previously defined extensions are
brought forward into TLS 1.3.  I suspect that they are all listed in
section 4.2, but is it clearly stated that those, and only those, are
grandfathered in?

Presumably, for any referenced extension, the placement of values in
messages in TLS 1.2 has a "natural" analog in TLS 1.3 that at most
involves moving the value from one field to another in certain
messages.  But it would be reassuring to have a clear statement of
this, and an enumeration of any more complex cases.

There are about 28 error codes but nearly 150 places where the text
require the connection to be aborted with an error.  There are 19
alone for "illegal_parameter".  I would like to see an "alert
extension value" which assigns a distinct "minor" code to each
statement in the text that