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

[Dan Harkins]

On Mon, April 4, 2016 8:50 am, Phil Lello wrote:
> On Mon, Apr 4, 2016 at 3:36 PM, Dan Harkins  wrote:
>
>>
>> Usually what happens is the server generates a self-signed certificate
>> and the apps are given some "username" and "password" and the app
>> ignores the unauthenticated nature of the TLS connection and sends
>> the u/p credential on through.
>
> Isn't this use case more of an argument for an updated auth-digest to use
> something better than MD5? I'm not convinced MITM is a real concern for a
> typical IoT environment (however that's defined - I'm assuming http in a
> domestic environment).

  First of all, what makes you think it's MD5 digest and not just
plaintext? And updated by whom? These are ad hoc constructions done
because the alternative is too onerous.

  As someone who has stolen wi-fi from the apt next door that was
protected by a PSK I would say that doing a dictionary attack in
a "domestic environment" is entirely plausible. If I have to do a
soft AP advertising the neighbor's SSID in order to lure a set-top
box or thermostat or whatever to connect to me then that's a very
low bar.

  regard,

  Dan.



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

[TLS] Asymmetric TLS

[Phil Lello]

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

Re: [TLS] Call for consensus: Removing 0-RTT client auth

[Subodh Iyengar]

If DH 0-RTT client auth is removed, most apps will start using client auth with 
PSK 0-RTT handshakes which is the current state in TLS 1.2 (with tickets) as 
Bill previous mentioned. We've encountered implications of this when using 
TLS1.2 for internal authentication. The tradeoff here is that a server that 
shares a ticket key with another server can masquerade as any client to the 
other server. This is a performance / security tradeoff here, and we solve this 
using partitioning of ticket keys between untrustworthy servers. There are 
several other implications of session tickets that we already deal with for 
this security / performance tradeoff, and this is not the worst one. 

I don't think having some form of 0-RTT client auth is a bad thing since there 
are engineering implications of not providing client auth during 0-RTT. 
A server app is using TLS for cert authentication and doing it's own 
authorization, it might provide certain methods to be accessible without 
authorization, but others with authorization. In a lot of application 
protocols, the client would not know about this aproiri. Not having a form of 
client auth would obviate these from using 0-RTT completely which would be sad.

Since 0-RTT DH is still under discussion, maybe we should revisit 0-RTT DH 
client auth after that is decided?

Subodh Iyengar

From: TLS [tls-boun...@ietf.org] on behalf of Dan Harkins [dhark...@lounge.org]
Sent: Sunday, April 03, 2016 5:43 PM
To: Sean Turner
Cc: tls@ietf.org
Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth

  Hi Sean & Joe,

On Tue, March 29, 2016 5:59 am, Sean Turner wrote:
> All,
>
> To make sure we’ve got a clear way forward coming out of our BA
> sessions, we need to make sure there’s consensus on a couple of
> outstanding issues.  So...
>
> It seems that there is a clear consensus not to support 0-RTT client
> authentication in TLS 1.3 at this time.  If you think 0-RTT client
> authentication needs to be supported please indicate so now and provide
> your rationale.

  I don't think it needs to be supported and would be happy if
it was removed. It's a dangerous and flawed feature. My concern
is that if (which I fear is pronounced "when") an exploit is found
it might be easy to remove in a browser update but there's gonna
be some large TLS concentrator vendor that'll have a helluva time
getting its deployed boxes patched and it'll be ugly.

  The rationale for this-- to get an ad to me just that much faster
(an ad, I note, that I sure hope my ad blocking software will prevent
me from seeing), and that the people who want to do this know what
they're doing so it'll all be fine (which is not reassuring in the
least)-- just does not justify the risk.

  regards,

  Dan.


___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=CwIFaQ=5VD0RTtNlTh3ycd41b3MUw=h3Ju9EBS7mHtwg-wAyN7fQ=0Wl8UysaIyWxp0Iw_9TKo4jE9Iwn7DnABCdnYWj_2Kk=2SuDKxG_YMEaEm1zqgKy4-aHt4NzUB9QVq8SzByaqp8=

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

Re: [TLS] Avoiding Trial Decryption (for 0-RTT)

[Kaduk, Ben]

On 4/2/16, 14:53, "Karthik Bhargavan"  wrote:

>
>Here is a proposal that would avoid trial decryption.
>When the client sends 0-RTT application data, it currently
>ends this flight of messages with an encrypted end_of_early data warning alert.
>How about: if the server rejects trial decryption, the client
>must then send an *unencrypted* end_of_early_data warning alert before
>continuing with 1-RTT handshake data.
>The server could then easily discard all records until it sees this warning 
>alert.
>
>The main disadvantage of this approach seems to be that it reveals to the 
>adversary
>the point at which the 0-RTT application data ends (if this is sensitive 
>information.)
>However, note that if the length of 0-RTT data was sensitive, an attacker
>could probably already obtain it by delaying the server flight.
>
>Does anyone see other practical or security disadvantages to using this alert?

I tried to think of ways that a misbehaving client (or attacker) could cause a 
server relying on the unencrypted alert to consume resources and sit around 
waiting for a long time, but it seems like the unencrypted alert is strictly 
better than trial decryption in that regard (since the server doesn't have to 
burn CPU on decryption).  So, it seems that revealing the length of the 0-RTT 
data is the main disadvantage, but as Ilari notes, there are likely to be other 
channels that would leak that boundary in many cases.

Using the unencrypted alert does also provide a clear indication that the 
client/server failed to exchange 0-RTT data; for a PSK mode with a cache of 
0-RTT sessions this could provide a window into the validity periods used by 
the two parties or as a signal that a finite-sized cache is full and ejecting 
old entries.  Perhaps an attacker could use that signal to determine the rate 
of some other sort of attack that requires getting a session evicted from the 
cache, but the need for such a signal seems pretty hypothetical, given that an 
attacker can already claim to be as many different clients as it wants.

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

[Peter Gutmann]

Watson Ladd  writes:

>Why can't embedded devices use certificates?

Because they have neither a DNS name nor a fixed IP address.  I ran into this
just last week with a customer, they couldn't use certs for their embedded
devices and couldn't use PSK because the browser vendors have chosen not to
support it.  As a result, they abandoned the use of TLS altogether and went
with SSH.

Peter.
___
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

[Salz, Rich]

> > Not always; ISO et al.
> 
>   That's why I said "basically"; it's a qualifier.

I know; I was trying to emphasize, not correct :).
 
>   But keep in mind what kind of stable, publicly available document needs to
> be published: a description not of the algorithm but of how that algorithm
> get crammed into the TLS exchange

 That is a good point.  But most offerings we have seen so far are about 
national bulk encryption ciphers and not, say, new key-exchange methods (GOST 
the only one so far?).  Of course that might change.

___
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

[Watson Ladd]

On Mon, Apr 4, 2016 at 7:05 AM, Dan Harkins  wrote:
>
>
> On Thu, March 31, 2016 10:51 am, Stephen Farrell wrote:
>>
>> If smaller devices don't use algorithms that can be used to talk to
>> random servers on the Internet, then they are choosing to not try to
>> get interop. That seems like a shame to me, unless there's a really
>> good reason and IMO, mostly there isn't, at the ciphersuite level. I
>> would hope we all won't make the GCM/CCM mistake again for example
>> (that "we" being roughly some combination of IETF/IEEE folks).
>
>   That's because you incorrectly define "interop" as talking to
> random servers on the Internet. This browser-centric mode of thinking
> causes you to reject cipher suites that the browser/webserver
> community does not have any interest in.
>
>   There are use cases where some app doesn't want to talk to random
> servers on the Internet. It wants to talk to a set of specific servers
> providing a specific stream of information unique to the app-- think
> of some network monitoring or RF-quality app that provides sensing
> data to servers and also sucks down neighbor air quality information
> as it roams around. There are IoT use cases where devices just want
> to talk to each other, not random servers on the Internet.
>
>   The browser community wants 0-RTT; I don't give a damn about 0-RTT.
> I want a PAKE (specifically TLS-pwd); the browser community doesn't
> give a damn about PAKEs. We are both right. Because we have different
> requirements.

Why can't embedded devices use certificates?



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

___
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

[Dan Harkins]

On Thu, March 31, 2016 10:51 am, Stephen Farrell wrote:
>
> If smaller devices don't use algorithms that can be used to talk to
> random servers on the Internet, then they are choosing to not try to
> get interop. That seems like a shame to me, unless there's a really
> good reason and IMO, mostly there isn't, at the ciphersuite level. I
> would hope we all won't make the GCM/CCM mistake again for example
> (that "we" being roughly some combination of IETF/IEEE folks).

  That's because you incorrectly define "interop" as talking to
random servers on the Internet. This browser-centric mode of thinking
causes you to reject cipher suites that the browser/webserver
community does not have any interest in.

  There are use cases where some app doesn't want to talk to random
servers on the Internet. It wants to talk to a set of specific servers
providing a specific stream of information unique to the app-- think
of some network monitoring or RF-quality app that provides sensing
data to servers and also sucks down neighbor air quality information
as it roams around. There are IoT use cases where devices just want
to talk to each other, not random servers on the Internet.

  The browser community wants 0-RTT; I don't give a damn about 0-RTT.
I want a PAKE (specifically TLS-pwd); the browser community doesn't
give a damn about PAKEs. We are both right. Because we have different
requirements.

> So I think the proposed change here, if it leads to fewer but more
> ubiquitously deployed ciphersuites, will help smaller devices. And I
> do think the IETF recommended column might lead us some way in that
> direction.

  Fewer is better... for one set of requirements, there's no reason to
have umpteen (> 2) ways of meeting the requirements. But to approach
this issue as if there is only one set of requirements (being able
to talk to random web servers on the Internet) is to cram a multiplicity
of differently shaped pegs into the proverbial round hole.

  regards,

  Dan.


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