[TLS] DPRIV has the downgrade too (Re: Consensus Call on draft-ietf-tls-dnssec-chain-extension)

[Nico Williams]

On Thu, Apr 05, 2018 at 02:46:12AM -0400, Viktor Dukhovni wrote:
> So I rather suspect that even the DPRIV use-case, which supposedly does not 
> need
> the proposed changes, actually does need them for meaningful security from 
> using
> DANE, and we've not just not looked at the details closely enough yet.  It may
> well turn out not substantially different from the browser use-case that is 
> not
> adequately met by the current draft.
> 
> Can someone explain briefly how DPRIV avoids the same downgrade issues, and
> negative adoption incentives (cost-benfit comparison)?  If it turns out that
> no adequate explanation is possible, and indeed the same issues are present,
> then the proposed changes (which are still needed elsewhere) are all the
> more pressing.

Oh, right, DPRIV isn't a work-in-progress.  It's already here.  Thus it
cannot be an application that makes draft-ietf-tls-dnssec-chain-extension
mandatory.  Therefore it's subject to the downgrade attack we want to
address with (C).

I think now the WG should really want this LC to succeed and get this
change made.

Nico
-- 

___
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  en nombre de Stan Kalisch 

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]

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

[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

[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

[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

[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

[TLS] [DTLS]: how to handle unknown identity and bad psk ?

[Simon Bernard]

Hi,

We are implementing DTLS with PSK over UDP and I would like to know how 
"unknown identity" and "bad psk" should be handled


Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says :
(https://tools.ietf.org/html/rfc4279#section-2)

>   If the server does not recognize the PSK identity, it MAY respond
>   with an "unknown_psk_identity" alert message. Alternatively, if the
>   server wishes to hide the fact that the PSK identity was not known,
>   it MAY continue the protocol as if the PSK identity existed but the
>   key was incorrect: that is, respond with a "decrypt_error" alert.

In TLS the safer way seems to send a "decrypt_error" alert for both.

But in DTLS :
https://tools.ietf.org/html/rfc6347#section-4.1.2.7

>   In general, invalid records
>   SHOULD be silently discarded, thus preserving the association;
>   however, an error MAY be logged for diagnostic purposes.
>   Implementations which choose to generate an alert instead, MUST
>   generate fatal level alerts to avoid attacks where the attacker
>   repeatedly probes the implementation to see how it responds to
>   various types of error.  Note that if DTLS is run over UDP, then any
>   implementation which does this will be extremely susceptible to
>   denial-of-service (DoS) attacks because UDP forgery is so easy.
>   Thus, this practice is NOT RECOMMENDED for such transports.

Is this record layer recommendation for all type of record ? even 
HANDSHAKE(22) record (and so FINISHED message) or is it mainly for 
APPLICATION_DATA(23) record ?


Is it acceptable to send fatal alert "decrypt_error" in DTLS or should 
we just ignore bad credentials silently ?


--
Simon

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

Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ?

[Eric Rescorla]

On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard 
wrote:

> Hi,
>
> We are implementing DTLS with PSK over UDP and I would like to know how
> "unknown identity" and "bad psk" should be handled
>
> Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says :
> (https://tools.ietf.org/html/rfc4279#section-2)
>
> >   If the server does not recognize the PSK identity, it MAY respond
> >   with an "unknown_psk_identity" alert message. Alternatively, if the
> >   server wishes to hide the fact that the PSK identity was not known,
> >   it MAY continue the protocol as if the PSK identity existed but the
> >   key was incorrect: that is, respond with a "decrypt_error" alert.
>
> In TLS the safer way seems to send a "decrypt_error" alert for both.
>
> But in DTLS :
> https://tools.ietf.org/html/rfc6347#section-4.1.2.7
>
> >   In general, invalid records
> >   SHOULD be silently discarded, thus preserving the association;
> >   however, an error MAY be logged for diagnostic purposes.
> >   Implementations which choose to generate an alert instead, MUST
> >   generate fatal level alerts to avoid attacks where the attacker
> >   repeatedly probes the implementation to see how it responds to
> >   various types of error.  Note that if DTLS is run over UDP, then any
> >   implementation which does this will be extremely susceptible to
> >   denial-of-service (DoS) attacks because UDP forgery is so easy.
> >   Thus, this practice is NOT RECOMMENDED for such transports.
>
> Is this record layer recommendation for all type of record ? even
> HANDSHAKE(22) record (and so FINISHED message) or is it mainly for
> APPLICATION_DATA(23) record ?
>
> Is it acceptable to send fatal alert "decrypt_error" in DTLS or should we
> just ignore bad credentials silently ?
>

Hi  Simon,

The advice in 4279 is basically "make an unknown identity look like a bad
key". So the idea would be to just randomize the key and then get the TLS
or DTLS-type behavior. I.e., with TLS you would send decrypt_error and in
DTLS the handshake would just stall because you would drop packets.

-Ekr

--
> Simon
>
> ___
> 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