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] Breaking into TLS for enterprise "visibility" (don't do it)

[Vakul Garg]

Hi Martin

> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Rex
> Sent: Thursday, March 29, 2018 4:47 AM
> To: Steve Fenter 
> Cc: tls@ietf.org
> Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)
> 
> Steve Fenter  wrote:
> >
> > To clarify for anyone who has confusion on the enterprise TLS
> > visibility use case, I think enterprises need to be able to do
> > out-of-band decryption anywhere in the network that they own.
> 
> This is argument is so lame.
> 
> In Germany, monitoring communications between individuals or between
> individuals and legal entities, including communications over corporate
> networks, was made a serious crime in 2004 (TKG 2004) with a penalty of up
> to 5 years in prison for listening into such communication.
> 
> The world didn't end.  Really, consider it proven that there is no need.
> 
 
Could monitoring could be legally done if user provided his consent at the time 
of 
login into enterprise managed terminal? 
I guess that's the case in enterprise managed networks.

> There may be _desires_.  For me, those desires are no less unethical as data
> collections by apple, camebridge analytica, facebook, google, microsoft,
> whathaveyou...
> 
>  and fortunately, for corporations in germany, such data gathering is not
> just unethical, but truely criminal by law.
> 
> 
> -Martin
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.ietf.org%2Fmailman%2Flistinfo%2Ftls=02%7C01%7Cvakul.garg%40n
> xp.com%7C17aacd25ee5c49568aca08d595021677%7C686ea1d3bc2b4c6fa9
> 2cd99c5c301635%7C0%7C0%7C636578758559728633=sa3hcM4C94
> %2BX826Xcu4BwvfkIFzfJiB8cjPjOh7s8pI%3D=0

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