Re: [TLS] Asymmetric TLS

2016-04-05 Thread Bill Frantz
To avoid a lot of "Over my dead body" comments, these 
requirements should be met with a very visible man in the middle 
and two (or more) TLS sessions. This architecture should provide 
some security from unwanted men in the middle, as well as making 
it obvious to the endpoints who that man in the middle is.


Cheers - Bill

On 4/5/16 at 10:29 AM, s...@sn3rd.com (Sean Turner) wrote:

With my chair hat on, I won’t comment one way or the other on 
whether this should be done, but we have gone down this path 
before.  As I recall, the proposal was pretty resoundingly rejected.


But, what I will say as chair is that this would most definitely require a 
charter change for the WG.

spt


On Apr 04, 2016, at 14:24, Phil Lello  wrote:

Hi,

I have a use-case for allowing an MITM to monitor traffic, but not impersonate 
a server, and to allow MITM signing for replay of

server-responses to support caching.


As far as I'm aware, TLS currently only supports a shared-secret once session 
initialisation is complete, so I'd need to extend the

protocol to support asymmetric encryption for the session.


Would there be interest in extending TLS to:
- allow monitoring-with-consent (based on asymmetric encryption)?
- allow re-signing from an authorised MITM to support caching?

Best wishes,

Phil Lello


---
Bill Frantz|"Web security is like medicine - trying to 
do good for

408-356-8506   |an evolved body of kludges" - Mark Miller
www.pwpconsult.com |

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


Re: [TLS] Asymmetric TLS

2016-04-05 Thread Stephen Farrell


On 05/04/16 18:29, Sean Turner wrote:
> But, what I will say as chair is that this would most definitely
> require a charter change for the WG.

FYI: you'd also have to climb over an AD-dead-body to get that.

S.



smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Asymmetric TLS

2016-04-05 Thread Sean Turner
With my chair hat on, I won’t comment one way or the other on whether this 
should be done, but we have gone down this path before.  As I recall, the 
proposal was pretty resoundingly rejected.

But, what I will say as chair is that this would most definitely require a 
charter change for the WG.

spt

> On Apr 04, 2016, at 14:24, Phil Lello  wrote:
> 
> Hi,
> 
> I have a use-case for allowing an MITM to monitor traffic, but not 
> impersonate a server, and to allow MITM signing for replay of 
> server-responses to support caching.
> 
> As far as I'm aware, TLS currently only supports a shared-secret once session 
> initialisation is complete, so I'd need to extend the protocol to support 
> asymmetric encryption for the session.
> 
> Would there be interest in extending TLS to:
>   - allow monitoring-with-consent (based on asymmetric encryption)?
>   - allow re-signing from an authorised MITM to support caching?
> 
> Best wishes,
> 
> Phil Lello
> 
> ___
> 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] Asymmetric TLS

2016-04-05 Thread Salz, Rich
On 4 April 2016 at 14:24, Phil Lello  wrote:
> Would there be interest in extending TLS to:
>   - allow monitoring-with-consent (based on asymmetric encryption)?
>   - allow re-signing from an authorised MITM to support caching?

This is very bad; no.

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


Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

2016-04-05 Thread Peter Gutmann
Adam Langley  writes:

>Ideas for supporting this case (i.e. the "I want to do HTTPS to my router"
>problem) in browsers have done the rounds a few times.

This isn't for HTTPS to a router, it's to SCADA devices.  The preferred
interface to them is HTTPS, but since browsers have refused to implement
anything other than cert-based TLS, there's nothing that can be done.

>The reason that nothing has happened is that it's a lot of work to do it
>right

How hard can it be to implement TLS-PSK?  I did it in a few hours in my crypto
library.

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