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

> 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

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

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 draf

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

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

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

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

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

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

, 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 rev

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,

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

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

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

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

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

>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

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

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

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

>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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

+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

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

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