Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS

[Viktor S. Wold Eide]

On Thu, Aug 27, 2015 at 1:18 PM, Eric Rescorla  wrote:

>
>
> On Thu, Aug 27, 2015 at 2:14 AM, Viktor S. Wold Eide <
> viktor.s.wold.e...@gmail.com> wrote:
>
>> On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla  wrote:
>>
>>>
>>>
>>> TLS 1.3 encrypts both the client's and server's certificates already.
>>> The server's certificate is secure only against passive attack. The
>>> client's is encrypted with a key that the client can authenticate as
>>> belonging to the server.
>>>
>>>
>>
>> It's good to see that both the client's and the server's certificates are
>> encrypted in TLS 1.3, providing protection against passive eavesdropping.
>>
>> For some use cases it might be worthwhile to reduce the information made
>> available to an active attacker also. Are there any suggestions in this
>> direction for TLS 1.3?
>>
>> One might think of a multi stage approach, something like:
>> - Anonymous connection establishment, resulting in a secure channel.
>> - Authentication by means of group certificate.
>> - Authentication by means of a host specific certificate.
>>
>> The purpose of the second step above is to first only provide the group
>> identity to an active attacker, and then to reveal the host identities
>> (certificate information) only after group membership has been mutually
>> authenticated
>>
>
> I don't think this matches most TLS use cases very well, since the client
> generally isn't authenticated at all, so there's no point in the server
> progressively
> revealing more.
>
>
Although the client generally is not authenticated currently, TLS 1.3 and
DTLS 1.3 are likely to stay for a long time and then to be used for lots of
different use cases, including more peer-to-peer interaction. For some
use-cases, including peer-to-peer interaction, being able to progressively
reveal more information would improve protection. Whether this is a
worthwhile tradeoff or not, depends on many different factors. I think it
is both relevant and interesting to see to what extent (D)TLS 1.3 would
support such use cases.

Best regards
Viktor S. Wold Eide
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS

[Viktor Dukhovni]

On Fri, Aug 28, 2015 at 04:27:28PM +0200, Viktor S. Wold Eide wrote:

> > I don't think this matches most TLS use cases very well, since the client
> > generally isn't authenticated at all, so there's no point in the server
> > progressively
> > revealing more.
> >
> >
> Although the client generally is not authenticated currently, TLS 1.3 and
> DTLS 1.3 are likely to stay for a long time and then to be used for lots of
> different use cases, including more peer-to-peer interaction. For some
> use-cases, including peer-to-peer interaction, being able to progressively
> reveal more information would improve protection. Whether this is a
> worthwhile tradeoff or not, depends on many different factors. I think it
> is both relevant and interesting to see to what extent (D)TLS 1.3 would
> support such use cases.

It seems that with TLS 1.3 the client MUST send SNI, presumably in
the clear.  Typically there's not much else of interest in the
server certificate to hide.  I don't see a realistic way to hide
the server identity even from passive wiretap via TLS.

Encryption of the TCP layer, plus TLS channel-binding (or
super-encryption) might be necessary to limit the metadata leakage
to just the transport layer endpoint addresses.  With IPsec the
leakage is just the network layer addresses.

Is anyone looking into leveraging TCPinc (when available) in TLS?
Extract channel-binding data from the socket, authenticate it with
TLS, and perhaps use TLS with NULL ciphers and if possible a
simplified handshake...

-- 
Viktor.

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

Re: [TLS] [tls13-spec] expand MTI Extensions and add more strict requirements (#232)

[Salz, Rich]

Having discussions through github is a really bad idea.  Mail formatting can 
get even more mangled, and we lose the IETF mail archive and participation.  I 
think we need to be more diligent and avoid doing that.

> There's just no statement of what to do when it's required and not given.

That's not necessarily a problem.  The behavior of the other party need not be 
strictly defined.  It can send an alert or continue along as best as it wants.  
Merely describing what must be done is enough.  Very few specs fully mandate 
what must be done if all the requirements are not met; I think XML was the 
first widespread Internet one to do so.

/r$

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Dave Garrett]

On Friday, August 28, 2015 11:08:35 am Salz, Rich wrote:
> Having discussions through github is a really bad idea.

You're right. I posted a stupidly long side-note in there. I intended to bring 
it to the list too, which I'll do now.

On Friday, August 28, 2015 10:49:33 am Viktor Dukhovni wrote:
> It seems that with TLS 1.3 the client MUST send SNI, presumably in
> the clear.  Typically there's not much else of interest in the
> server certificate to hide.  I don't see a realistic way to hide
> the server identity even from passive wiretap via TLS.

Currently, we're at implementations MUST support (not necessarily send) SNI, 
servers MAY require it, and servers SHOULD error on such a failed requirement. 
This doesn't change the status quo much. If servers don't require it, you don't 
need to send it. HTTP/2 has its own SNI requirement, though, so lots of TLS 
will be moving in that direction.

The idea I had the other day is that we can technically do SNI encryption with 
the current TLS 1.3 draft, as-is. All that needs to really be done is stick it 
in a 0-RTT EncryptedExtensions, preferably only when the server specifies that 
it is allowed via adding a flag to server config. This would require the actual 
server share the 0-RTT DH key across the virtual servers it's picking via SNI, 
so early data probably should be off in this instance for many use-cases.

The simplest route that would allow for encrypted SNI with 0-RTT application 
data allowed would be to just add a second long-term DH key to the server 
config for SNI (and an option for servers to have one do both if they don't 
need two). Seeing as this would still need to be opt-in via a flag in the 
config, we could use the same extension ID and just encrypt it using the second 
key. Servers that provide an SNI key get encrypted; others get clear or none.

If we can also get a way to distribute server config out-of-band, this would 
even allow initial-connection SNI encryption.

I don't think encrypted SNI to servers without any prior information is really 
that viable, and that's been said before by others on this list. Now, with that 
said, you could just create a way for any client to ask a server for its config 
without any attempt to connect right away, in which case it can follow up with 
encrypted SNI at the cost of that 1-RTT (e.g. the QUIC way of doing things). 
Even if we allow ServerConfiguration to be optional normally, we could add this 
config request mode and make support for that mandatory (though, potentially 
with short-lived keys). This route would still require some prior information 
about this server: knowledge that it could request a key for SNI at all without 
just getting rejected. Doing so without that would require a multiple attempt 
check of some kind that's probably a bad idea.


Dave

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

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Viktor Dukhovni]

On Fri, Aug 28, 2015 at 12:13:03PM -0400, Dave Garrett wrote:

> The idea I had the other day is that we can technically do SNI encryption
> with the current TLS 1.3 draft, as-is. All that needs to really be done
> is stick it in a 0-RTT EncryptedExtensions, preferably only when the server
> specifies that it is allowed via adding a flag to server config. This
> would require the actual server share the 0-RTT DH key across the virtual
> servers it's picking via SNI, so early data probably should be off in this
> instance for many use-cases.

So the client would now need to cache some session data by transport
address, and other data by name and port.  That's rather complex.
And how often will the same client visit multiple servers at the
same transport address?

I don't really see this as viable or worth the effort.

> I don't think encrypted SNI to servers without any prior information is
> really that viable, and that's been said before by others on this list.

I don't think SNI hiding is viable without encryption at the
transport or network layers.  And there's still a metadata leak
via DNS which may prove difficult to address.

-- 
Viktor.

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

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Salz, Rich]

> > The idea I had the other day is that we can technically do SNI
> > encryption with the current TLS 1.3 draft, as-is.

Yeah, some of us talked about this in Dallas, etc., when the "semi-static EDH 
key" really started to take hold.  I showed slides at the interim before IETF 
90 in Toronto, that seemed to convince everyone that it doesn't really get you 
the privacy you think you get.  (I couldn't find them in the meeting materials; 
if anyone wants the PDF let me know.) There's still the DNS leakage, to which 
dkg reasonably points out that we should not succumb to the deadly embrace of 
each component waiting for the other.

> And how often will the same client visit multiple servers at the same
> transport address?

Anyone who visits sites hosted by a CDN.  And, I suspect, many large portals.
 
> I don't really see this as viable or worth the effort.

Agree.

/r$

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

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Dave Garrett]

On Friday, August 28, 2015 12:33:31 pm Salz, Rich wrote:
> > And how often will the same client visit multiple servers at the same
> > transport address?
> 
> Anyone who visits sites hosted by a CDN.  And, I suspect, many large portals.

How's it done with IPv6, generally? Are there setups where everyone is sharing 
a v6 IP? We could eventually get to the point where a reverse DNS lookup is all 
that's needed for everyone if things were set up smartly. Probably a better 
setup for things to work, but worse for passive surveillance. (though, IPv6 
could eventually let clients randomize their IP frequently, which helps some 
things; getting off-topic here, though)

> > I don't really see this as viable or worth the effort.
> 
> Agree.

I agree that it's a lot of effort for relatively little gain. I might be worth 
considering, but if the consensus is that TLS just isn't designed to do this 
easily enough to be worth it, then I don't really dispute a decision to just 
drop the concept.


Dave

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

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Salz, Rich]

> How's it done with IPv6, generally?

We don't see address-sharing with IPv6, although I wonder if that will change 
when the routing tables get too big. :)  We also don't see anyone willing to go 
IPv6-only; it's not close to universal enough yet.

> I agree that it's a lot of effort for relatively little gain.

It doesn't protect those who need it against those who would harm them.

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

[TLS] I-D Action: draft-ietf-tls-tls13-08.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the 
IETF.

Title   : The Transport Layer Security (TLS) Protocol Version 
1.3
Author  : Eric Rescorla
Filename: draft-ietf-tls-tls13-08.txt
Pages   : 103
Date: 2015-08-28

Abstract:
   This document specifies Version 1.3 of the Transport Layer Security
   (TLS) protocol.  The TLS protocol allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-tls13-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[TLS] draft-ietf-tls-tls13-08 and plan for future drafts

[Eric Rescorla]

Folks,

I've just posted draft-08 which includes the changes discussed on-list
to require digital signatures from the client even if you are re-using
a previous configuration in 0-RTT (per WG discussion).

This version also includes a bunch of other cleanup, as detailed below:

- Remove support for weak and lesser used named curves.

- Remove support for MD5 and SHA-224 hashes with signatures.

- Revise list of currently available AEAD cipher suites.

- Reduce maximum permitted record expansion for AEAD from 2048 to 256
octets.

- Require digital signatures even when a previous configuration is used.

- Merge EarlyDataIndication and KnownConfiguration.

- Change code point for server_configuration to avoid collision with
  server_hello_done.

As usual, comments welcome. If you think I missed something important
please let me know and/or file a github issue so I don't forget it
this time.


I thought it might be useful for people to know what's coming in
upcoming drafts.

1. As I mentioned in Prague, I plan to do a fairly significant
restructuring/editorial effort to make things easier to read.
This will include:

- Reordering the text to put the overview first.
- Cleaning up or removing obsolete/redundant material
  (e.g., the now really old security analysis)
- General editorial cleanup.


1. The intention is to produce a cleaned-up draft that doesn't have any
major
technical changes (optimally no technical changes) but is
significantly easier to read. I'm targeting that for early September.
I'll keep a github branch up to date on this in case people want to
see how it's going.

2. In parallel I'll be starting threads on the list to try to resolve
a number of open technical issues. Hopefully we can deal with a bunch
of this on the list and get the rest on-deck for the interim in SEA.

Depending on the timeline and the number of issues we resolve, I may
do a -09 and then have -10 be the rewrite, or -09 may just be the
rewrite.

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

[TLS] Deprecate DH_anon in favor of raw public keys?

[Eric Rescorla]

https://github.com/tlswg/tls13-spec/issues/233

Folks,

We presently have some support for DH_anon cipher suites. I agree that this
is a useful use case, but it's yet another mode.

I would like to suggest that we instead deprecate it and instead always use
Raw Public Key mode (https://tools.ietf.org/html/rfc7250). The idea is that
the client would simply indicate support for a raw public key and the
server could then either (a) spin a new key for this use or (b) use a
long-term
one. To my mind this has three advantages:

1. Complexity: It means that we have one less operational mode. And all the
public key
modes would look cryptographically similar.

2. It resolves the question of how you bind to the server's identity in
0-RTT mode
(https://github.com/tlswg/tls13-spec/issues/219), namely the raw public key
that goes in the Certificate message.

3. It makes it easier to do an SSH-style leap-of-faith mode since the
server can
use the same signing key for a long time while maintaining PFS.

It seems to me that the two major counterarguments are:

1. Extra computational cost from the signature. I'm not worried too much
about that since generally the anonymous contexts don't do a lot of
connections
and we don't really want to encourage pure anonymous (i.e., non-TOFU) modes
anyway.

2. It's less explicit that this is unverified. Arguably this is a feature
rather than
a bug.

Thoughts?
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Deprecate DH_anon in favor of raw public keys?

[Dave Garrett]

I actually had this in my old a la carte proposal. Here's the relevant section 
posted separately, unedited, except for keeping the current list of RFCs with 
anon that weren't in that proposal:

https://github.com/tlswg/tls13-spec/compare/master...davegarrett:unauthenticated


Dave

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

Re: [TLS] Deprecate DH_anon in favor of raw public keys?

[Martin Thomson]

This seems fine to me, though I'll note that 7250 only really saves
you space when it comes down to it.  You can wrap your raw public key
in a certificate, just like we do in WebRTC, and then you don't need
7250 support in your library.  Noting you can only do any of these
variations in a context where there is some preexisting understand
that what you choose to use is acceptable to the other side.

Regarding the explicit nature of having an explicit DH_anon signal, I
tend to think that (on balance) removing this signal does more good
than harm.  I expect certain others to disagree, of course, but we can
talk about why a vigorous defense of the cipher suite signal isn't a
good use of their energy later.

On 28 August 2015 at 10:35, Eric Rescorla  wrote:
> https://github.com/tlswg/tls13-spec/issues/233
>
> Folks,
>
> We presently have some support for DH_anon cipher suites. I agree that this
> is a useful use case, but it's yet another mode.
>
> I would like to suggest that we instead deprecate it and instead always use
> Raw Public Key mode (https://tools.ietf.org/html/rfc7250). The idea is that
> the client would simply indicate support for a raw public key and the
> server could then either (a) spin a new key for this use or (b) use a
> long-term
> one. To my mind this has three advantages:
>
> 1. Complexity: It means that we have one less operational mode. And all the
> public key
> modes would look cryptographically similar.
>
> 2. It resolves the question of how you bind to the server's identity in
> 0-RTT mode
> (https://github.com/tlswg/tls13-spec/issues/219), namely the raw public key
> that goes in the Certificate message.
>
> 3. It makes it easier to do an SSH-style leap-of-faith mode since the server
> can
> use the same signing key for a long time while maintaining PFS.
>
> It seems to me that the two major counterarguments are:
>
> 1. Extra computational cost from the signature. I'm not worried too much
> about that since generally the anonymous contexts don't do a lot of
> connections
> and we don't really want to encourage pure anonymous (i.e., non-TOFU) modes
> anyway.
>
> 2. It's less explicit that this is unverified. Arguably this is a feature
> rather than
> a bug.
>
> Thoughts?
> -Ekr
>
>
>
>
> ___
> 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] Deprecate DH_anon in favor of raw public keys?

[Eric Rescorla]

On Fri, Aug 28, 2015 at 11:07 AM, Martin Thomson 
wrote:

> This seems fine to me, though I'll note that 7250 only really saves
> you space when it comes down to it.  You can wrap your raw public key
> in a certificate, just like we do in WebRTC, and then you don't need
> 7250 support in your library.


It also removes the need to parse the cert.



> Noting you can only do any of these
> variations in a context where there is some preexisting understand
> that what you choose to use is acceptable to the other side.
>

SG.



> Regarding the explicit nature of having an explicit DH_anon signal, I
> tend to think that (on balance) removing this signal does more good
> than harm.  I expect certain others to disagree, of course, but we can
> talk about why a vigorous defense of the cipher suite signal isn't a
> good use of their energy later.
>
> On 28 August 2015 at 10:35, Eric Rescorla  wrote:
> > https://github.com/tlswg/tls13-spec/issues/233
> >
> > Folks,
> >
> > We presently have some support for DH_anon cipher suites. I agree that
> this
> > is a useful use case, but it's yet another mode.
> >
> > I would like to suggest that we instead deprecate it and instead always
> use
> > Raw Public Key mode (https://tools.ietf.org/html/rfc7250). The idea is
> that
> > the client would simply indicate support for a raw public key and the
> > server could then either (a) spin a new key for this use or (b) use a
> > long-term
> > one. To my mind this has three advantages:
> >
> > 1. Complexity: It means that we have one less operational mode. And all
> the
> > public key
> > modes would look cryptographically similar.
> >
> > 2. It resolves the question of how you bind to the server's identity in
> > 0-RTT mode
> > (https://github.com/tlswg/tls13-spec/issues/219), namely the raw public
> key
> > that goes in the Certificate message.
> >
> > 3. It makes it easier to do an SSH-style leap-of-faith mode since the
> server
> > can
> > use the same signing key for a long time while maintaining PFS.
> >
> > It seems to me that the two major counterarguments are:
> >
> > 1. Extra computational cost from the signature. I'm not worried too much
> > about that since generally the anonymous contexts don't do a lot of
> > connections
> > and we don't really want to encourage pure anonymous (i.e., non-TOFU)
> modes
> > anyway.
> >
> > 2. It's less explicit that this is unverified. Arguably this is a feature
> > rather than
> > a bug.
> >
> > Thoughts?
> > -Ekr
> >
> >
> >
> >
> > ___
> > 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] Deprecate DH_anon in favor of raw public keys?

[Viktor Dukhovni]

On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote:

> This seems fine to me, though I'll note that 7250 only really saves
> you space when it comes down to it.  You can wrap your raw public key
> in a certificate, just like we do in WebRTC, and then you don't need
> 7250 support in your library.  Noting you can only do any of these
> variations in a context where there is some preexisting understand
> that what you choose to use is acceptable to the other side.

Indeed that's effectively what you get with DANE TLSA "3 1 1", when
the client, the server or at present typically both don't support
RFC 7250.

> Regarding the explicit nature of having an explicit DH_anon signal, I
> tend to think that (on balance) removing this signal does more good
> than harm.  I expect certain others to disagree, of course, but we can
> talk about why a vigorous defense of the cipher suite signal isn't a
> good use of their energy later.

The signal has pros and cons.  Absent channel-binding at the next
layer up, it makes it clear to adversaries that active attacks are
"safe".  On the other hand, it allows servers to detect that a
client is not planning to authenticate the server, which has forensic
value, and can be used to grant appropriately restricted access.

Furthermore, anon-DH has strong privacy properties, the server
sends no identity information, not even a public key.  Any
channel-binding at the next layer is privacy protected.

The proposal to use raw public keys sends a similar signal to
servers that don't publish DANE-EE(3)/SPKI(1) TLSA records.  X.509
clients can no longer to PKIX authentication.  A server that does
publish DANE-EE(3)/SPKI(1) records on the other hand can no longer
conclude that authentication is not done.  And of course clients
may be doing public key pinning, be it TOFU, or via some out-of-band
means.

Clearly getting along without anon_DH is possible, since many
servers or clients don't enable anon_DH ciphers and yet interoperate
just fine with those that do.  

My view is that anon_DH should either be supported properly (be
defined for the same symmetric cipher combinations as ciphersuites
with certs or public keys) or as proposed not supported at all.

Replacement by public keys is not semantically equivalent, it just
saves a bit of network and code space relative to self-signed X.509.
So I'm not yet convinced that the proposal is progress, we lose
some and gain some.

-- 
Viktor.

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

Re: [TLS] Deprecate DH_anon in favor of raw public keys?

[Eric Rescorla]

On Fri, Aug 28, 2015 at 11:33 AM, Viktor Dukhovni 
wrote:

> On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote:
>
> > This seems fine to me, though I'll note that 7250 only really saves
> > you space when it comes down to it.  You can wrap your raw public key
> > in a certificate, just like we do in WebRTC, and then you don't need
> > 7250 support in your library.  Noting you can only do any of these
> > variations in a context where there is some preexisting understand
> > that what you choose to use is acceptable to the other side.
>
> Indeed that's effectively what you get with DANE TLSA "3 1 1", when
> the client, the server or at present typically both don't support
> RFC 7250.
>
> > Regarding the explicit nature of having an explicit DH_anon signal, I
> > tend to think that (on balance) removing this signal does more good
> > than harm.  I expect certain others to disagree, of course, but we can
> > talk about why a vigorous defense of the cipher suite signal isn't a
> > good use of their energy later.
>
> The signal has pros and cons.  Absent channel-binding at the next
> layer up, it makes it clear to adversaries that active attacks are
> "safe".  On the other hand, it allows servers to detect that a
> client is not planning to authenticate the server, which has forensic
> value, and can be used to grant appropriately restricted access.
>
> Furthermore, anon-DH has strong privacy properties, the server
> sends no identity information, not even a public key.  Any
> channel-binding at the next layer is privacy protected.
>

How does anon-DH have different privacy properties than doing
RFC 7250 with a fresh signing key for each connection?

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

Re: [TLS] Deprecate DH_anon in favor of raw public keys?

[Martin Thomson]

On 28 August 2015 at 11:36, Eric Rescorla  wrote:
> How does anon-DH have different privacy properties than doing
> RFC 7250 with a fresh signing key for each connection?

Or what we do in WebRTC, which uses a certificate that has no good
information in it?

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

Re: [TLS] Deprecate DH_anon in favor of raw public keys?

[Martin Thomson]

On 28 August 2015 at 11:33, Viktor Dukhovni  wrote:
> On the other hand, it allows servers to detect that a
> client is not planning to authenticate the server, which has forensic
> value, and can be used to grant appropriately restricted access.


I think that these are potentially useful properties, but I don't
think that we need to use the cipher suite signaling to get that
information.  What if you could (for example) include a signal at the
application layer "oh, by the way, I didn't authenticate you".  Or you
could have an extension that said up front that you don't intend to
check.  Those are superior in the sense that it allows for all the
benefits of ekr's proposal, without losing the properties you care
about.

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

[TLS] DSA support in TLS 1.3.

[Dang, Quynh]

Hi all,


DSA is supported in the previous versions of TLS. It would be nice if someone 
who uses DSA can use it in TLS 1.3 as well.


People who don't use DSA, then they don't use DSA. People who use DSA right, it 
should be fine for them to use DSA.


I don't see a convincing reason to remove support of DSA in TLS 1.3.


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

Re: [TLS] Deprecate DH_anon in favor of raw public keys?

[Ronald del Rosario]

"Or what we do in WebRTC, which uses a certificate that has no good
information in it?”

+1. Anxiously waiting for response on this, as I am currently helping 
non-profit groups build a private and secure P2P Messaging System using WebRTC, 
which of course utilizes encrypted P2P connection between two browsers (A 
centralized signaling server must be at the middle as a broker for the sessions)

The DTLS handshake performed between two WebRTC clients re-lies on self-signed 
certificates. As a result, the certificates themselves cannot be used to 
authenticate the peer, as there is no explicit chain of trust to verify.

Ron


From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Martin Thomson mailto:martin.thom...@gmail.com>>
Date: Friday, August 28, 2015 at 11:44 AM
To: Eric Rescorla mailto:e...@rtfm.com>>
Cc: "tls@ietf.org" mailto:tls@ietf.org>>
Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys?

Or what we do in WebRTC, which uses a certificate that has no good
information in it?



CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain 
confidential information of Five9 and/or its affiliated entities. Access by the 
intended recipient only is authorized. Any liability arising from any party 
acting, or refraining from acting, on any information contained in this e-mail 
is hereby excluded. If you are not the intended recipient, please notify the 
sender immediately, destroy the original transmission and its attachments and 
do not disclose the contents to any other person, use it for any purpose, or 
store or copy the information in any medium. Copyright in this e-mail and any 
attachments belongs to Five9 and/or its affiliated entities.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Ilari Liusvaara]

On Fri, Aug 28, 2015 at 07:17:39PM +, Dang, Quynh wrote:
> Hi all,
> 
> DSA is supported in the previous versions of TLS. It would be nice
> if someone who uses DSA can use it in TLS 1.3 as well.

Well, at least for the web, DSA is no longer an option because
major browsers have dropped support for it.

> People who don't use DSA, then they don't use DSA. People who use
> DSA right, it should be fine for them to use DSA.

Unfortunately, it is not just signers, it is also verifiers.
 
> I don't see a convincing reason to remove support of DSA in TLS 1.3.

Well, no (projected) use. Many features have been stripped from TLS
1.3 on those grounds only.


Also, if DSA was to be supported, one would need to specify how to
determine the hash function (use of fixed SHA-1 doesn't fly). And
1024-bit prime is too small.



-Ilari

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

Re: [TLS] DSA support in TLS 1.3.

[Sean Turner]

Quynh,

You must have been reading my mind because I’m working on something that will 
help Joe and I judge consensus on what to do about DSA.

Let’s hold off on this thread for a bit while I get that msg together.

spt

On Aug 28, 2015, at 15:17, Dang, Quynh  wrote:

> Hi all, 
> 
> DSA is supported in the previous versions of TLS. It would be nice if someone 
> who uses DSA can use it in TLS 1.3 as well. 
> 
> People who don't use DSA, then they don't use DSA. People who use DSA right, 
> it should be fine for them to use DSA.
> 
> I don't see a convincing reason to remove support of DSA in TLS 1.3.
> 
> Quynh. 
> ___
> 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] DSA support in TLS 1.3.

[Hanno Böck]

On Fri, 28 Aug 2015 19:17:39 +
"Dang, Quynh"  wrote:

> DSA is supported in the previous versions of TLS. It would be nice if
> someone who uses DSA can use it in TLS 1.3 as well.

Do you have a plausible reason why you want to use DSA? Or is this
purely a theoretical consideration?
Because this discussion came up multiple times here and I can't
remember anyone having a real world use case for DSA. From net wide
scans it seems DSA certs are almost nonexistent.

> I don't see a convincing reason to remove support of DSA in TLS 1.3.

The reason is avoiding feature bloat. I think it makes a lot of sense
to question the support of features nobody uses. Therefore I'm very
interested to hear why anybody would want to use DSA. "Just because
someone could" isn't a good reason.
(Also DSA has a well-known weakness with bad random numbers.)

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpNMWVrh6boY.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Tony Arcieri]

On Friday, August 28, 2015, Dang, Quynh  wrote:
>
> People who don't use DSA, then they don't use DSA. People who use DSA
> right, it should be fine for them to use DSA.
>
Can you name one of these people? If not, you seem to be arguing for
including legacy protocols with no real-world use case in mind.

In absence of real-world use cases, removing legacy baggage from TLS
reduces attack surface and makes things easier for implementers.


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

Re: [TLS] DSA support in TLS 1.3.

[Viktor Dukhovni]

On Fri, Aug 28, 2015 at 01:27:57PM -0700, Tony Arcieri wrote:

> On Friday, August 28, 2015, Dang, Quynh  wrote:
> >
> > People who don't use DSA, then they don't use DSA. People who use DSA
> > right, it should be fine for them to use DSA.
> >
> Can you name one of these people? If not, you seem to be arguing for
> including legacy protocols with no real-world use case in mind.
> 
> In absence of real-world use cases, removing legacy baggage from TLS
> reduces attack surface and makes things easier for implementers.

Also *improves* interoperability, because the client HELLO carries
fewer cipher-suite code points, helping with systems that are
intolerant of large HELLO messages or only process a subset of the
indicated ciphers.

-- 
Viktor.

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

Re: [TLS] DSA support in TLS 1.3.

[Dave Garrett]

On Friday, August 28, 2015 04:21:53 pm Hanno Böck wrote:
> On Fri, 28 Aug 2015 19:17:39 +
> "Dang, Quynh"  wrote:
> > I don't see a convincing reason to remove support of DSA in TLS 1.3.
> 
> The reason is avoiding feature bloat. I think it makes a lot of sense
> to question the support of features nobody uses.

At minimum, it's almost certainly getting cut from the TLS 1.3 specification 
document. It's obsolete, even by DSS standards, and either needs significant 
updating (e.g. use SHA-2) or dropping. The question will likely be whether it 
should be considered no longer acceptable or something which is permitted, just 
rarely supported and described in another document. I'd rather just declare it 
obsolete and no longer permitted to avoid the attack surface and complexity, 
and I get an impression that this is a common opinion in the WG.


Dave

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

Re: [TLS] DSA support in TLS 1.3.

[Tony Arcieri]

On Fri, Aug 28, 2015 at 1:59 PM, Dave Garrett 
wrote:

> I'd rather just declare it obsolete and no longer permitted to avoid the
> attack surface and complexity, and I get an impression that this is a
> common opinion in the WG.


+1. Most people seem to oppose its inclusion, and the people asking for it
to be retained do not seem to have real-world use cases.

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

Re: [TLS] DSA support in TLS 1.3.

[Jacob Appelbaum]

On 8/28/15, Dang, Quynh  wrote:
> Hi all,
>
>
> DSA is supported in the previous versions of TLS. It would be nice if
> someone who uses DSA can use it in TLS 1.3 as well.
>
>
> People who don't use DSA, then they don't use DSA. People who use DSA right,
> it should be fine for them to use DSA.
>
>
> I don't see a convincing reason to remove support of DSA in TLS 1.3.
>

What do you suggest for the construction of the k value in DSA? The
old NSA backdoor that leaks the private key? Or perhaps a different
NIST endorsed construction?

All the best,
Jacob

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

Re: [TLS] DSA support in TLS 1.3.

[Dave Garrett]

On Friday, August 28, 2015 08:41:23 pm Jacob Appelbaum wrote:
> What do you suggest for the construction of the k value in DSA?

https://tools.ietf.org/html/rfc6979#section-3.2 ?

Also, we still have ECDSA, so the 'k' issue isn't going away. Should we cite 
this RFC?


Dave

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

Re: [TLS] DSA support in TLS 1.3.

[Jeffrey Walton]

>
> Also, if DSA was to be supported, one would need to specify how to
> determine the hash function (use of fixed SHA-1 doesn't fly). And
> 1024-bit prime is too small.
>
FIPS186-4 (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
partially remediates the issue. DSA now includes 2048 and 3072 sizes.

Jeff

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

Re: [TLS] DSA support in TLS 1.3.

[Geoffrey Keating]

Jeffrey Walton  writes:

> >
> > Also, if DSA was to be supported, one would need to specify how to
> > determine the hash function (use of fixed SHA-1 doesn't fly). And
> > 1024-bit prime is too small.
> >
> FIPS186-4 (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
> partially remediates the issue. DSA now includes 2048 and 3072 sizes.

This is true, but if TLS 1.3 was to specify DSA, it should require the
2048 or 3072 sizes (since 1024 is last century's crypto), and existing
implementations do not necessarily support those today.

Which really highlights the question: who would actually use it?
ECDSA can be smaller, faster, and more secure all at once; and if you
don't like ECDSA or want an alternative, there's RSA.

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

Re: [TLS] DSA support in TLS 1.3.

[Ronald del Rosario]

> "ECDSA can be smaller, faster, and more secure all at once; and if you don't 
> like ECDSA or want an alternative, there's RSA."
>
Isn't that a step backward reverting to RSA?

Ron F. Del Rosario



CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain 
confidential information of Five9 and/or its affiliated entities. Access by the 
intended recipient only is authorized. Any liability arising from any party 
acting, or refraining from acting, on any information contained in this e-mail 
is hereby excluded. If you are not the intended recipient, please notify the 
sender immediately, destroy the original transmission and its attachments and 
do not disclose the contents to any other person, use it for any purpose, or 
store or copy the information in any medium. Copyright in this e-mail and any 
attachments belongs to Five9 and/or its affiliated entities.

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