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

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

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

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

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

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

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

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

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

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

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

> 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

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,

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

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

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

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 : >