Re: [TLS] Broken browser behaviour with SCADA TLS

[Martin Thomson]

On Wed, Jul 4, 2018 at 4:53 PM Peter Gutmann  wrote:
> ... Client negotiates non-PFS pure-RSA and ignores PFS DHE ...

How is the client doing any of this?  The server picks the cipher suite.

> Least broken browser: Firefox (at least for the last proper version they 
> released)

Newer versions might not have DHE, which I hope is consistent with
your expectations.  But we haven't started on those plans.  As of the
latest version, things should be the same - extensions shouldn't
affect whether connections work.

The problem with DHE of course being that it uses the TLS 1.0 suites
with the SHA1 MAC and with the MAC and encrypt in the wrong order.
And that it is subject to small subgroup attacks from the server
unless it negotiates the FFDHE extension.

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

Re: [TLS] Broken browser behaviour with SCADA TLS

[Ilari Liusvaara]

On Wed, Jul 04, 2018 at 05:05:08PM +1000, Martin Thomson wrote:
> On Wed, Jul 4, 2018 at 4:53 PM Peter Gutmann  
> wrote:
> > ... Client negotiates non-PFS pure-RSA and ignores PFS DHE ...
> 
> How is the client doing any of this?  The server picks the cipher suite.
> 
> > Least broken browser: Firefox (at least for the last proper version they 
> > released)
> 
> Newer versions might not have DHE, which I hope is consistent with
> your expectations.  But we haven't started on those plans.  As of the
> latest version, things should be the same - extensions shouldn't
> affect whether connections work.
> 
> The problem with DHE of course being that it uses the TLS 1.0 suites
> with the SHA1 MAC and with the MAC and encrypt in the wrong order.
> And that it is subject to small subgroup attacks from the server
> unless it negotiates the FFDHE extension.

More serious problem is servers returning too small modulus due lack
of negotiation. Which was the reason why Chrome disabled DHE.


Also, there are finite-field AEAD ciphersuites in TLS 1.2, which do
not use the broken blockmode nor SHA-1 (but Firefox does not appear to
support any of these):

- AES, ARIA or CAMELLIA in GCM mode, with 128 or 256 bit keys, and with
  RSA or DSS certificate (good luck getting DSS certificate, and even
  more luck getting clients to accept it).
- AES in CCM mode, with 128 or 256 bit keys and 64 or 128 bit tags. Only
  RSA certificates are supported.
- CHACHA20-POLY1305-AEAD with 256 bit keys. Only RSA certificates are
  supported.



-Ilari

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

Re: [TLS] Broken browser behaviour with SCADA TLS

[Peter Gutmann]

Martin Thomson  writes:

>How is the client doing any of this?  The server picks the cipher suite.

Sorry, I meant the client only offers pure-RSA, not DHE+RSA, so the server is
forced to pick pure-RSA, e.g.:

Chrome:

Offered suite: TLS_RSA_WITH_AES_128_CBC_SHA.
Accepted suite: TLS_RSA_WITH_AES_128_CBC_SHA.
Offered suite: TLS_RSA_WITH_AES_256_CBC_SHA.
Offered suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA.

This is on a system without ECDHE present, so the server is looking for DHE
(preferentially) or RSA (if it really has to), the ECDHE suites are skipped.
This was noticed on systems which had disabled the pure-RSA suites because
some industry compliance thing required it, and found that Chrome was now
unusable for any of their devices.

(My suggestion that they might consider QQ Browser didn't go down too
well...).

>Newer versions might not have DHE, which I hope is consistent with your
>expectations

Well, that'd bring FF closer to Chrome's brokenness.  I guess I could add a
comment about FF copying everything Chrome does as being consistent with my
expectations :-).

>As of the latest version, things should be the same - extensions shouldn't
>affect whether connections work.

Sure, the only reason for mentioning the "last version with extensions" is
that apparently some of the systems require browser extensions, and they
aren't going to be rewritten for current versions of Firefox.  So it was
whatever the last version with extensions was, either 52ESR or 56 (I didn't
ask, I'm on FF 56).

>The problem with DHE of course being that it uses the TLS 1.0 suites with the
>SHA1 MAC and with the MAC and encrypt in the wrong order. 

Given that SHA-1 is used in the HMAC form it doesn't really matter security-
wise... the order of MAC and encrypt also depends on EtM/LTS support, I didn't
check for who does what there, the real issue was to report on browser issues
when used in a SCADA environment and to poke vendors with a bit of a WTF?! for
their cipher suite support, or lack thereof.  Currently the best by a long
shot is FF.

Peter.

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

Re: [TLS] Broken browser behaviour with SCADA TLS

[Peter Gutmann]

Ilari Liusvaara  writes:

>More serious problem is servers returning too small modulus due lack of
>negotiation. Which was the reason why Chrome disabled DHE.

Why not reject the handshake if the modulus is too small, rather than
disabling all DHE suites on the off chance that the server returns a value you
don't like?

>- AES, ARIA or CAMELLIA in GCM mode, with 128 or 256 bit keys, and with
>  RSA or DSS certificate (good luck getting DSS certificate, and even
>  more luck getting clients to accept it).
>- AES in CCM mode, with 128 or 256 bit keys and 64 or 128 bit tags. Only
>  RSA certificates are supported.
>- CHACHA20-POLY1305-AEAD with 256 bit keys. Only RSA certificates are
>  supported.

Wouldn't matter much anyway, suport for those is practically nonexistent (CCM,
Aria, Camellia, ChaCha20, and so on, I mean).

OK, "practically nonexistent" may be too optimistic, I've never heard of
anything supporting those.  Having said that I don't know of every SCADA
device in existence, maybe some Korean devices somewhere do Aria.

DSA certs aren't a problem since they're all from non-commercial CAs (in-house
or self-signed), but I only know of a few systems using DSA.  Can't remember
why they did that... oh yes, because keygen was faster/more efficient for DSA,
just a single modexp and no requirement for lots of CPU and memory.

Peter.

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

Re: [TLS] Broken browser behaviour with SCADA TLS

[Ilari Liusvaara]

On Wed, Jul 04, 2018 at 07:57:41AM +, Peter Gutmann wrote:
> Ilari Liusvaara  writes:
> 
> >More serious problem is servers returning too small modulus due lack of
> >negotiation. Which was the reason why Chrome disabled DHE.
> 
> Why not reject the handshake if the modulus is too small, rather than
> disabling all DHE suites on the off chance that the server returns a value you
> don't like?

Chrome initially did that. It caused quite a lot of bad feedback from
owners of various bad embedded stuff. The thread on relevant forums was
quite something. Hundreds of messages blaming Google for breaking
stuff.


-Ilari

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

Re: [TLS] Broken browser behaviour with SCADA TLS

[Nikos Mavrogiannopoulos]

On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote:
> On Wed, Jul 04, 2018 at 07:57:41AM +, Peter Gutmann wrote:
> > Ilari Liusvaara  writes:
> > 
> > > More serious problem is servers returning too small modulus due
> > > lack of
> > > negotiation. Which was the reason why Chrome disabled DHE.
> > 
> > Why not reject the handshake if the modulus is too small, rather
> > than
> > disabling all DHE suites on the off chance that the server returns
> > a value you
> > don't like?
> 
> Chrome initially did that. It caused quite a lot of bad feedback from
> owners of various bad embedded stuff. The thread on relevant forums
> was
> quite something. Hundreds of messages blaming Google for breaking
> stuff.

We had similar experience when we required a minimum of 2048-bit
modulus for all TLS connections in Fedora 28 beta irrespective of back-
end lib. It broke connections to VPN servers and web internal web sites
and we had to revert the change. The DHE ciphersuites under TLS1.2 seem
doomed and rfc7919 couldn't save them.

regards,
Nikos

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

Re: [TLS] Broken browser behaviour with SCADA TLS

[Martin Thomson]

On Wed, 4 Jul. 2018, 18:42 Nikos Mavrogiannopoulos, 
wrote:

> We had similar experience when we required a minimum of 2048-bit
> modulus for all TLS connections in Fedora 28 beta irrespective of back-
> end lib. It broke connections to VPN servers and web internal web sites
> and we had to revert the change. The DHE ciphersuites under TLS1.2 seem
> doomed and rfc7919 couldn't save them.
>

It has been suggested that 7919 makes things worse.

We have minimum modulus size constraints and haven't had any reports of
issues, but the limits are fairly low and we have a less diverse usage
environment than Redhat.

We're also unable to catch big values that aren't prime, or values with
small subgroups. We end up trusting servers more than we might consider ok
for a modern protocol. That isn't a massive problem in my view.

Of course, our recommendations don't change. Right now, that is to use TLS
1.3, or at least the configuration of TLS 1.2 that most closely resembles
1.3. The rest is stuff we merely tolerate for the sake of interoperability.
Soon, I hope, we might be able to get rid of TLS 1.0 and 1.1, and these
questions will be somewhat less interesting.

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

[TLS] Malformed Finished handling

[Hubert Kario]

Despite this, is it correct to terminate a connection with "illegal_parameter" 
upon receiving a Finished handshake message with a 100 byte payload? or a 20 
byte payload? My opinion is that it is not, "decode_error" is more specific so 
it should be used instead.


Specification says the following on the matter:

The draft 28 specifies the Finished message as having following structure:

  struct {
  opaque verify_data[Hash.length];
  } Finished;

At multiple places it also talks about handling messages that have sizes that 
don't match their structure as requiring termination of connection with 
"decode_error".

The generic situation in Section 6: 

   Peers which receive a message which
   cannot be parsed according to the syntax (e.g., have a length
   extending beyond the message boundary or contain an out-of-range
   length) MUST terminate the connection with a "decode_error" alert.

as description of the alert in Section 6.2:

   decode_error  A message could not be decoded because some field was
  out of the specified range or the length of the message was
  incorrect.  This alert is used for errors where the message does
  not conform to the formal protocol syntax.

In specific about Client Hello, in Section 4.1.2:

   If negotiating a version of TLS prior to 1.3, a server MUST check
   that the message either contains no data after
   legacy_compression_methods or that it contains a valid extensions
   block with no data following.  If not, then it MUST abort the
   handshake with a "decode_error" alert.

And specific handling of Certificate from server in Section 4.4.2.4:

   If the server supplies an empty Certificate message, the client MUST
   abort the handshake with a "decode_error" alert.

Description of "illegal_parameter" in Section 6:

   Peers which receive a message which is syntactically correct but
   semantically invalid (e.g., a DHE share of p - 1, or an invalid enum)
   MUST terminate the connection with an "illegal_parameter" alert.

Alert description in Section 6.2:

   illegal_parameter  A field in the handshake was incorrect or
  inconsistent with other fields.  This alert is used for errors
  which conform to the formal protocol syntax but are otherwise
  incorrect.

(it's also mentioned in over a dozen places in the draft)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Broken browser behaviour with SCADA TLS

[Hubert Kario]

On Wednesday, 4 July 2018 09:45:36 CEST Peter Gutmann wrote:
> Martin Thomson  writes:
> >As of the latest version, things should be the same - extensions shouldn't
> >affect whether connections work.
> 
> Sure, the only reason for mentioning the "last version with extensions" is
> that apparently some of the systems require browser extensions, and they
> aren't going to be rewritten for current versions of Firefox.  So it was
> whatever the last version with extensions was, either 52ESR or 56 (I didn't
> ask, I'm on FF 56).

what "browser extensions"? you can't really do a modern TLS 1.2 without 
extensions, let alone TLS 1.3 (which is now enabled by default in NSS). I'm 
quite sure NSS didn't drop any consequential ones...

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Broken browser behaviour with SCADA TLS

[Kurt Roeckx]

On Wed, Jul 04, 2018 at 12:01:18PM +0200, Hubert Kario wrote:
> what "browser extensions"? you can't really do a modern TLS 1.2 without 
> extensions, let alone TLS 1.3 (which is now enabled by default in NSS). I'm 
> quite sure NSS didn't drop any consequential ones...

The extensions are not related to TLS, but are extentions /
add-ons of the browser itself. Firefox dropped support for the
old way of doing extensions in version 57. They also added the
WebExtensions API that is also implemented in other browsers.
This required major rewrites of the extensions, and some were
never changed to work with the new API.


Kurt

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

[TLS] [PSA] 0-RTT tolerance is mandatory

[Hubert Kario]

All the implementations I deal with in my day-to-day work fail to handle the 
0-RTT client hello correctly when the 0-RTT support is not enabled on the 
server.

I.e. they ignore the MUST clause from
https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating that the 
server can handle an early_data extension (and following encrypted data) in 
only one of three ways, neither which allows for unconditional connection 
abort.

This also runs afoul the recommendation from https://tools.ietf.org/html/
draft-ietf-tls-tls13-28#section-D.3 on 0-RTT backwards compatibility.

Quick test can be performed by running the tlsfuzzer script.
Start a server on port 4433 (or use the -p switch to the test case to change 
it) on localhost (or use -h switch to provide ip or hostname) with support for 
draft-28, a RSA server key, support for P-256 ECDH, AES-128-GCM cipher and 
SHA-256 signature hash. The server needs to be able to respond to a record 
with an HTTP GET query (i.e. either HTTP server or an echo server will work).

Download the requirements:
git clone https://github.com/tomato42/tlsfuzzer
pushd tlsfuzzer
# won't be needed after tlsfuzzer#423 PR is merged
git checkout 0rtt-garbage-resumption
git clone https://github.com/tomato42/tlslite-ng .tlslite-ng
ln -s .tlslite-ng/tlslite tlslite
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa

Run the test case:
PYTHONPATH=. python scripts/test-tls13-0rtt-garbage.py

successful run will print
Test end
successful: 3
failed: 0

at the end

the test case supports also --num-bytes switch to provide how big the early 
data should be (sends 2^14B by default).
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DNS-based Encrypted SNI

[Eric Rescorla]

On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara 
wrote:

> On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:=
> > I am working on an implementation for NSS/Firefox and I know some
> > others are working on their own implementations, so hopefully we can
> > do some interop in Montreal.
> >
> > This is at a pretty early stage, so comments, questions, defect
> > reports welcome.
>
> One thing I noticed: First there is this in evaluation:
>
> 7.2.4.  Do not stick out
>
>By sending SNI and ESNI values (with illegitimate digests), or by
>sending legitimate ESNI values for and "fake" SNI values, clients do
>not display clear signals of ESNI intent to passive eavesdroppers.
>
> Is that suggesting to send fake ESNI values? If so, there is this in
> endpoint behavior:
>

No, you would not send fake ESNI values. The idea here is that there is a
group of IPs (associated with a big provider, then all ESNI-supporting
clients will send ESNI to it. So the provider will stick out, but the use
of site X versus site Y on the provider will notstick out. And the
provider's IPs are reasonably well known through other mechanisms, so this
doesn't tell you much. Of course, this does not help big sites that aren't
using shared infrastructure (e.g., Facebook), but I don't know how to do
that.

-Ekr


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

Re: [TLS] Malformed Finished handling

[Eric Rescorla]

I think it's a close call, because the length is sort of external to the
language. That's why, for instance, NSS sends "illegal_parameter". So,
absent specific text about this value, I think this is something we can
leave to the implementations.

-Ekr




On Wed, Jul 4, 2018 at 2:54 AM, Hubert Kario  wrote:

> Despite this, is it correct to terminate a connection with
> "illegal_parameter"
> upon receiving a Finished handshake message with a 100 byte payload? or a
> 20
> byte payload? My opinion is that it is not, "decode_error" is more
> specific so
> it should be used instead.
>
>
> Specification says the following on the matter:
>
> The draft 28 specifies the Finished message as having following structure:
>
>   struct {
>   opaque verify_data[Hash.length];
>   } Finished;
>
> At multiple places it also talks about handling messages that have sizes
> that
> don't match their structure as requiring termination of connection with
> "decode_error".
>
> The generic situation in Section 6:
>
>Peers which receive a message which
>cannot be parsed according to the syntax (e.g., have a length
>extending beyond the message boundary or contain an out-of-range
>length) MUST terminate the connection with a "decode_error" alert.
>
> as description of the alert in Section 6.2:
>
>decode_error  A message could not be decoded because some field was
>   out of the specified range or the length of the message was
>   incorrect.  This alert is used for errors where the message does
>   not conform to the formal protocol syntax.
>
> In specific about Client Hello, in Section 4.1.2:
>
>If negotiating a version of TLS prior to 1.3, a server MUST check
>that the message either contains no data after
>legacy_compression_methods or that it contains a valid extensions
>block with no data following.  If not, then it MUST abort the
>handshake with a "decode_error" alert.
>
> And specific handling of Certificate from server in Section 4.4.2.4:
>
>If the server supplies an empty Certificate message, the client MUST
>abort the handshake with a "decode_error" alert.
>
> Description of "illegal_parameter" in Section 6:
>
>Peers which receive a message which is syntactically correct but
>semantically invalid (e.g., a DHE share of p - 1, or an invalid enum)
>MUST terminate the connection with an "illegal_parameter" alert.
>
> Alert description in Section 6.2:
>
>illegal_parameter  A field in the handshake was incorrect or
>   inconsistent with other fields.  This alert is used for errors
>   which conform to the formal protocol syntax but are otherwise
>   incorrect.
>
> (it's also mentioned in over a dozen places in the draft)
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
> ___
> 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] DNS-based Encrypted SNI

[Stephen Farrell]

Hiya,

On 03/07/18 00:39, Eric Rescorla wrote:
> Hi folks,
> 
> I just submitted:
> 
>   https://tools.ietf.org/html/draft-rescorla-tls-esni-00

Thanks for writing that up. I think it's an interesting
addition to the set of potential solutions.

> 
> This draft describes a DNS-based approach to doing encrypted SNI.
> 
> Previously, we had thought this wouldn't work because only sites that
> were particularly vulnerable would do it, and so the use of ESNI marks
> you out. The idea behind this draft is that there are a lot of sites
> which are hosted by -- and whose DNS is run by -- a large provider,
> and that provider can shift many if not all of its sites to ESNI at
> once, thus removing the "standing out" issue and making a DNS-based
> approach practical.

I'm not sure I fully understand how this approach would fit
with others, nor to what extent it depends on the DNS and
CDN providers co-operating, but it definitely seems worth
exploring.

> 
> I am working on an implementation for NSS/Firefox and I know some
> others are working on their own implementations, so hopefully we can
> do some interop in Montreal.
> 
> This is at a pretty early stage, so comments, questions, defect
> reports welcome.

Quick comments after flicking through the draft:

- I'm not that fussed myself as to whether this uses a TXT
or new RRTYPE. But if the latter would work, it seems better.

- I didn't quite get what "all the domains" in 3.2 means. I
guess if a client uses non-encrypted sni for one of those,
it should still work, but I'm not clear if supporting esni
for any domain means that the provider has to decrypt esni
and then deal with successful decrypted sni values as if
the client had sent sni in clear. A concern is requiring
"all the domains" might make it hard to roll this out.

- I guess some form(s) of key rollover will be needed, ut
I'm not sure that not_before/not_after is the best way to
do that.

- The ESNIKeys structure generally seems a bit complicated,
it might be better to aim for simplifying that and maybe
making it more "zonefile friendly" (whether in a TXT RR
or not).

- It might be interesting to think about how this'd work
for e.g. the IETF web site (where ietf.org is hosted
locally but www.ietf.org is not), and for STARTTLS and
MX RRs. That's probably ok, but I've not gotten it
straight in my little head yet:-)

- Would it make sense to include the innocuous dummy sni
in the published RR, so that all clients use the same
one and stand out that bit less?

- 7.1 probably needs more work - I'm not sure that it's
that ok to use this with cleartext DNS. ISTM that DOH/DPRIVE,
or a client application that knows the ESNIKeys, are most
likely needed, but there's probably also some work to do
to analyse the recursive to authoritative interactions to
get the ESNIKeys even with DPRIVE.

Lastly, the topic of whether or not to try address this
problem is something that the WG has debated quite a bit,
and IIRC the consensus after that debate was to do work
on this (hence Christian's draft).

So I don't see any need to debate whether or not to work on
this is needed, and trying to re-open such a debate seems
somewhat disruptive to me. It is entirely reasonable to
consider what, if anything, widespread use of esni or other
approaches might break though. But going back to all this
"privacy at any cost" and "we're the enterprises" hyperbole
is not at all helpful IMO, so I hope we don't have to suffer
more rounds of that. But maybe that's inevitable with every
iteration of attempts to improve privacy sadly;-(

Cheers,
S.


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


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] [PSA] 0-RTT tolerance is mandatory

[Ilari Liusvaara]

On Wed, Jul 04, 2018 at 02:42:51PM +0200, Hubert Kario wrote:
> All the implementations I deal with in my day-to-day work fail to handle the 
> 0-RTT client hello correctly when the 0-RTT support is not enabled on the 
> server.
> 
> I.e. they ignore the MUST clause from
> https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating that the 
> server can handle an early_data extension (and following encrypted data) in 
> only one of three ways, neither which allows for unconditional connection 
> abort.
> 
> This also runs afoul the recommendation from https://tools.ietf.org/html/
> draft-ietf-tls-tls13-28#section-D.3 on 0-RTT backwards compatibility.

OTOH, such servers probably do not send out tickets allowing 0-RTT, so
any client attempting 0-RTT with such server is very broken.


-Ilari

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

Re: [TLS] DNS-based Encrypted SNI

[Ilari Liusvaara]

On Wed, Jul 04, 2018 at 05:56:07AM -0700, Eric Rescorla wrote:
> On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara 
> wrote:
> 
> > On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:=
> > > I am working on an implementation for NSS/Firefox and I know some
> > > others are working on their own implementations, so hopefully we can
> > > do some interop in Montreal.
> > >
> > > This is at a pretty early stage, so comments, questions, defect
> > > reports welcome.
> >
> > One thing I noticed: First there is this in evaluation:
> >
> > 7.2.4.  Do not stick out
> >
> >By sending SNI and ESNI values (with illegitimate digests), or by
> >sending legitimate ESNI values for and "fake" SNI values, clients do
> >not display clear signals of ESNI intent to passive eavesdroppers.
> >
> > Is that suggesting to send fake ESNI values? If so, there is this in
> > endpoint behavior:
> >
> 
> No, you would not send fake ESNI values. The idea here is that there is a
> group of IPs (associated with a big provider, then all ESNI-supporting
> clients will send ESNI to it. So the provider will stick out, but the use
> of site X versus site Y on the provider will notstick out. And the
> provider's IPs are reasonably well known through other mechanisms, so this
> doesn't tell you much. Of course, this does not help big sites that aren't
> using shared infrastructure (e.g., Facebook), but I don't know how to do
> that.

What does "with illegitimate digests" mean then?



-Ilari

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

Re: [TLS] [PSA] 0-RTT tolerance is mandatory

[Hubert Kario]

On Wednesday, 4 July 2018 15:06:27 CEST Ilari Liusvaara wrote:
> On Wed, Jul 04, 2018 at 02:42:51PM +0200, Hubert Kario wrote:
> > All the implementations I deal with in my day-to-day work fail to handle
> > the 0-RTT client hello correctly when the 0-RTT support is not enabled on
> > the server.
> > 
> > I.e. they ignore the MUST clause from
> > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating that
> > the server can handle an early_data extension (and following encrypted
> > data) in only one of three ways, neither which allows for unconditional
> > connection abort.
> > 
> > This also runs afoul the recommendation from https://tools.ietf.org/html/
> > draft-ietf-tls-tls13-28#section-D.3 on 0-RTT backwards compatibility.
> 
> OTOH, such servers probably do not send out tickets allowing 0-RTT, so
> any client attempting 0-RTT with such server is very broken.

please read Section D.3, it is spelled out in detail there why that's not the 
case


the short of it: the client has no way of knowing if it is connecting to the 
same server/instance/process it received the ticket from

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Malformed Finished handling

[Hubert Kario]

On Wednesday, 4 July 2018 15:00:18 CEST Eric Rescorla wrote:
> I think it's a close call, because the length is sort of external to the
> language.

which language? the decode_error alert description literally says "length of 
the message was incorrect."

> That's why, for instance, NSS sends "illegal_parameter". So,
> absent specific text about this value, I think this is something we can
> leave to the implementations.

but the text is explicit, if a message continues past message boundary, the 
correct response is decode_error. Decode_error is also consistent with the way 
above-expected length Client Hello MUST be handled.

Just because the description of the message uses a single opaque array doesn't 
make this message syntactically any different from other Handshake protocol 
message.

if the interpretation of "I know this _message_ _length_ is wrong because of 
some other values I negotiated before, so I'll send illegal_parameter" was 
correct, then overflow_error, decrypt_error and probably few others would also 
need to be replaced with illegal_parameter...
 
> -Ekr
> 
> On Wed, Jul 4, 2018 at 2:54 AM, Hubert Kario  wrote:
> > Despite this, is it correct to terminate a connection with
> > "illegal_parameter"
> > upon receiving a Finished handshake message with a 100 byte payload? or a
> > 20
> > byte payload? My opinion is that it is not, "decode_error" is more
> > specific so
> > it should be used instead.
> > 
> > 
> > Specification says the following on the matter:
> > 
> > The draft 28 specifies the Finished message as having following structure:
> >   struct {
> >   
> >   opaque verify_data[Hash.length];
> >   
> >   } Finished;
> > 
> > At multiple places it also talks about handling messages that have sizes
> > that
> > don't match their structure as requiring termination of connection with
> > "decode_error".
> > 
> > The generic situation in Section 6:
> >Peers which receive a message which
> >cannot be parsed according to the syntax (e.g., have a length
> >extending beyond the message boundary or contain an out-of-range
> >length) MUST terminate the connection with a "decode_error" alert.
> > 
> > as description of the alert in Section 6.2:
> >decode_error  A message could not be decoded because some field was
> >
> >   out of the specified range or the length of the message was
> >   incorrect.  This alert is used for errors where the message does
> >   not conform to the formal protocol syntax.
> > 
> > In specific about Client Hello, in Section 4.1.2:
> >If negotiating a version of TLS prior to 1.3, a server MUST check
> >that the message either contains no data after
> >legacy_compression_methods or that it contains a valid extensions
> >block with no data following.  If not, then it MUST abort the
> >handshake with a "decode_error" alert.
> > 
> > And specific handling of Certificate from server in Section 4.4.2.4:
> >If the server supplies an empty Certificate message, the client MUST
> >abort the handshake with a "decode_error" alert.
> > 
> > Description of "illegal_parameter" in Section 6:
> >Peers which receive a message which is syntactically correct but
> >semantically invalid (e.g., a DHE share of p - 1, or an invalid enum)
> >MUST terminate the connection with an "illegal_parameter" alert.
> > 
> > Alert description in Section 6.2:
> >illegal_parameter  A field in the handshake was incorrect or
> >
> >   inconsistent with other fields.  This alert is used for errors
> >   which conform to the formal protocol syntax but are otherwise
> >   incorrect.
> > 
> > (it's also mentioned in over a dozen places in the draft)
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Malformed Finished handling

[Salz, Rich]

>if the interpretation of "I know this _message_ _length_ is wrong because 
> of 
some other values I negotiated before, so I'll send illegal_parameter" was 
correct, then overflow_error, decrypt_error and probably few others would 
also 
need to be replaced with illegal_parameter...
  
I think the rigorousness of error codes is not at the same level as the rest of 
the document.  I'm fine with that.  I can understand why people developing test 
suites are frustrated. To me, it's like people arguing about whether the "list 
of errno values" in a syscall manpage must be completely comprehensive or not.  
Old-timers might remember when djb used to rail against the fact that close(2) 
could set errno to ENOSPACE when using AFS.

The WG spans a wide variety of views on errors and alerts. Some want to have 
only one, "bad packet," alert. Some want to add a textual explanation option.  
Woolgathering aside, I think the first sentence I wrote is 100% accurate.




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

Re: [TLS] Broken browser behaviour with SCADA TLS

[Salz, Rich]

>The following is an attempt to condense some off-list discussions with 
> SCADA
folks about the broken behaviour of some browsers when it comes to 
interaction
  

Thanks for doing this.  It's always useful to get real-world usage information, 
especially in the non-Web world.


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

Re: [TLS] Broken browser behaviour with SCADA TLS

[David Benjamin]

On Wed, Jul 4, 2018 at 4:41 AM Nikos Mavrogiannopoulos 
wrote:

> On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote:
> > On Wed, Jul 04, 2018 at 07:57:41AM +, Peter Gutmann wrote:
> > > Ilari Liusvaara  writes:
> > >
> > > > More serious problem is servers returning too small modulus due
> > > > lack of
> > > > negotiation. Which was the reason why Chrome disabled DHE.
> > >
> > > Why not reject the handshake if the modulus is too small, rather
> > > than
> > > disabling all DHE suites on the off chance that the server returns
> > > a value you
> > > don't like?
> >
> > Chrome initially did that. It caused quite a lot of bad feedback from
> > owners of various bad embedded stuff. The thread on relevant forums
> > was
> > quite something. Hundreds of messages blaming Google for breaking
> > stuff.
>
> We had similar experience when we required a minimum of 2048-bit
> modulus for all TLS connections in Fedora 28 beta irrespective of back-
> end lib. It broke connections to VPN servers and web internal web sites
> and we had to revert the change. The DHE ciphersuites under TLS1.2 seem
> doomed and rfc7919 couldn't save them.
>

Indeed. The bad feedback was not even at a 2048-bit minimum, but a mere
1024-bit minimum. (Chrome enabled far more DHE ciphers than others, so we
encountered a lot of this.) 2048-bit was completely hopeless. At the time
of removal, 95% of DHE negotiations made by Chrome used a 1024-bit minimum.
See here for details:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/ShRaCsYx4lk/46rD81AsBwAJ

I should add to that link that the "draft specification which fixes the
negotiation problems", now rfc7919, did not fix the problem. This was
pointed out here, but never incorporated to the document:
https://www.ietf.org/mail-archive/web/tls/current/msg18697.html

To the original email, it seems the second and third scenarios are
identical. Configuring ECDHE+ECDSA ciphers is a no-op if using an RSA
server key. The third and fourth scenarios are indeed unsurprising for a
browser that doesn't support DHE. You should instruct these folks to
configure ECDHE+RSA ciphers if they have RSA keys. Particularly in the
second scenario, it seems they're already implemented, just the server was
incorrectly configured to use the wrong ones.

DHE at acceptable sizes is quite slow anyway, so their servers may well
appreciate the speed boost. (Indeed, I often see DHE disabled in server
deployments as otherwise the poor servers would melt.)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Ben Schwartz]

On Tue, Jul 3, 2018 at 5:19 PM Brian Sniffen  wrote:

> Hanno Böck  writes:
>
> > So-called "Enterprise" infrastructure has delayed the work of this group
> > for at least a year. Noone of the people creating that mess has reached
> > out to this group to explain why they constantly break TLS - let alone
> > apologize for it.
> >
> > I believe there's a large overlap of the actors breaking TLS with the
> > actors who are worried about things like SNI encryption. I'm not sure I
> > see any reason not to consider these actors as anything but opposed to
> > the work of this group.
>
> Whoah!  I've been involved for years specifically to ask for care about
> encrypted SNI.  I don't know whether I break TLS; maybe opinions vary.
> But my concerns have been specific:
>
> First, at the engineering level, a requirement that servers do expensive
> cryptographic work in response to a first packet *and* an inability to
> charge that work to a user or application is a big problem.  It makes it
> too hard for users or applications to share a server, or leads to levels
> of address waste expensive even with IPv6.
>
> If we're going to have 0RTT and 1RTT and TCP Fast Open and ECDHE... then
> Encrypted SNI is a hard engineering problem!
>
> Second, at the architectural level, a serious question about whether
> this actually helps anybody, and if so whom?  I think the case of the
> Amnesty International worker in an oppressive dictatorship is almost
> certainly *not* helped by this work---see my questions about how many
> bits of security this provides against an adaptive adversary from this
> morning---and would like some clarity that this is about inhibiting the
> ISPs, from cafes through enterprises up to Comcast-TWC, from monkeying
> with user sessions.
>
>
> My concerns at the engineering level have been welcomed, recognized,
> validated, and addressed.  Not always exactly the way I'd like, but
> absolutely addressed in a way that's appropriate and sincere.  I saw the
> same with requests to re-insert RSA Kx late last year.  The PATIENT
> folks have gotten a fair hearing.
>
> My architectural concerns have been heard, somewhat less eagerly.  Some
> participants, including our colleagues who are vendors to enterprises
> and folks like Ben Schwartz, have been clear that they will not bring
> all their motivations and evidence to the table.


It's always exciting to see your name in print.  Is there something I can
do to help here?  I honestly have no idea who "folks like me" are, or what
we did that gave you this impression.


> I significantly
> discount their arguments and expect others to do the same---but not to
> zero.


This is pretty disheartening.

Always happy to discuss in person.  I'll be at the meeting in Montreal.

It means we need to check their work as we go, or actually trust
> them as people, but it *can't* be harder than keeping NSA/IA people on
> CFRG!
>
> Anyway, I think the PATIENT folks concerns about the engineering of TLS
> 1.3 have been heard, have been taken seriously, and have been
> addressed---same as mine or yours.  What I've seen of the architectural
> concerns leading to network-centric management and "tap" devices come
> down to claims about changes in architecture being too expensive,
> middleboxes being too expensive, changes to applications being too
> expensive, and general citation of an architecture only a few years old
> as immutable tradition.  Those claims have also been heard, plenty of
> folks have respectfully and diligently combed through them for evidence,
> and we've moved on.
>
> I bet that's frustrating and frightening for the folks writing from a
> world where those claims aren't faith-based---they're obvious.  They
> don't need citation any more than "China is a country"[1] needs
> citation.  Nonetheless, engineering conversations based on
> data-supported arguments continue to be welcome.
>
> -Brian
>
>
> Footnotes:
> [1]
> https://www.cia.gov/library/publications/the-world-factbook/geos/ch.html
>  but see also
> https://www.cia.gov/library/publications/the-world-factbook/geos/tw.html
>
> --
> Brian Sniffen
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


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

Re: [TLS] Broken browser behaviour with SCADA TLS

[Colm MacCárthaigh]

On Wed, Jul 4, 2018 at 8:15 AM, David Benjamin 
wrote:
>
> Indeed. The bad feedback was not even at a 2048-bit minimum, but a mere
> 1024-bit minimum. (Chrome enabled far more DHE ciphers than others, so we
> encountered a lot of this.) 2048-bit was completely hopeless. At the time
> of removal, 95% of DHE negotiations made by Chrome used a 1024-bit minimum.
> See here for details:
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/
> ShRaCsYx4lk/46rD81AsBwAJ
>

>From the server side: we found that enforcing a 2048-bit size was
unworkable, it breaks clients that will negotiate DHE but then fail when
the exchange happens, including versions of Java. Because the breakage
happens post-handshake, there was little recourse to fix it. We did look at
fingerprinting the clients and trying to use a different size for those,
but even that led to too high an error rate. So we removed DHE in general
and use ECDHE for FS.

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

Re: [TLS] Broken browser behaviour with SCADA TLS

[David Benjamin]

On Wed, Jul 4, 2018 at 11:15 AM David Benjamin 
wrote:

> On Wed, Jul 4, 2018 at 4:41 AM Nikos Mavrogiannopoulos 
> wrote:
>
>> On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote:
>> > On Wed, Jul 04, 2018 at 07:57:41AM +, Peter Gutmann wrote:
>> > > Ilari Liusvaara  writes:
>> > >
>> > > > More serious problem is servers returning too small modulus due
>> > > > lack of
>> > > > negotiation. Which was the reason why Chrome disabled DHE.
>> > >
>> > > Why not reject the handshake if the modulus is too small, rather
>> > > than
>> > > disabling all DHE suites on the off chance that the server returns
>> > > a value you
>> > > don't like?
>> >
>> > Chrome initially did that. It caused quite a lot of bad feedback from
>> > owners of various bad embedded stuff. The thread on relevant forums
>> > was
>> > quite something. Hundreds of messages blaming Google for breaking
>> > stuff.
>>
>> We had similar experience when we required a minimum of 2048-bit
>> modulus for all TLS connections in Fedora 28 beta irrespective of back-
>> end lib. It broke connections to VPN servers and web internal web sites
>> and we had to revert the change. The DHE ciphersuites under TLS1.2 seem
>> doomed and rfc7919 couldn't save them.
>>
>
> Indeed. The bad feedback was not even at a 2048-bit minimum, but a mere
> 1024-bit minimum. (Chrome enabled far more DHE ciphers than others, so we
> encountered a lot of this.) 2048-bit was completely hopeless. At the time
> of removal, 95% of DHE negotiations made by Chrome used a 1024-bit minimum.
> See here for details:
>

Oops, that sentence should have read:

"At the time of removal, 95% of DHE negotiations made by Chrome used a
1024-bit *group*."

That is, were we to have enforced a 2048-bit minimum, 95% of DHE
connections would have broken. With 5% of it salvageable, the TLS DHE code
points are not worth saving.


>
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/ShRaCsYx4lk/46rD81AsBwAJ
>
> I should add to that link that the "draft specification which fixes the
> negotiation problems", now rfc7919, did not fix the problem. This was
> pointed out here, but never incorporated to the document:
> https://www.ietf.org/mail-archive/web/tls/current/msg18697.html
>
> To the original email, it seems the second and third scenarios are
> identical. Configuring ECDHE+ECDSA ciphers is a no-op if using an RSA
> server key. The third and fourth scenarios are indeed unsurprising for a
> browser that doesn't support DHE. You should instruct these folks to
> configure ECDHE+RSA ciphers if they have RSA keys. Particularly in the
> second scenario, it seems they're already implemented, just the server was
> incorrectly configured to use the wrong ones.
>
> DHE at acceptable sizes is quite slow anyway, so their servers may well
> appreciate the speed boost. (Indeed, I often see DHE disabled in server
> deployments as otherwise the poor servers would melt.)
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Tony Arcieri]

On Tue, Jul 3, 2018 at 10:08 AM Bret Jordan  wrote:

> From my personal perspective, we need to be careful with all of these
> efforts. It feels like the pendulum has swung so far to one side, the side
> of privacy-at-any-cost, that we are unknowingly increasing the risk to
> individuals and organizations by enabling threat actors and intrusions sets
> to attack networks and clients without any level of protection from the
> network.
>

Speaking as an industry practitioner and network security professional,
don't trust the network. That is the entire purpose of TLS.

As one of my present job capacities I micromanage Juniper SRX firewall
rules. However, my personal view of the value provided is that it's a
defense-in-depth measure at best.

There are already many ways for attackers to take surprising and unexpected
paths through the network which are much more interesting and useful than
through a DNS+CDN's frontend terminator. Just as one example of such a path
which is incredibly hard to block is Amazon S3, where you can attempt to
whitelist a particular bucket by hostname, and even try to do NIDS to
ensure that S3 requests only go to mybucket.s3.amazonaws.com by inspecting
SNI and rejecting anything but a particular bucket in the SNI, but after
TLS has been established an attacker can send a Host: header of
attackerbucket.s3.amazonaws.com and S3 doesn't care what domain you used to
get there or what SNI you sent.


> It also feels like a lot of these initiatives are being done without
> adequately involving and ensuring that enterprise networks and critical
> infrastructure can work with these changes. Question, do we know how these
> ideas and changes are going to impact an organizations ability to fulfill
> their requirements for regulatory compliance?
>

I am a co-founder of a technology company, and was formerly on the
information security team of a publicly traded next-gen fintech company.
Speaking as a representative of industry, I would once again like to make
it very clear that demands for "visibility" represent one perspective
within industry as a whole. I think if it were possible to take a hum "from
industry", you would find it quite divided on this topic, particularly
between older larger companies and smaller, newer ones.

Having aided (in some cases instrumentally) with PCI-DSS, HIPAA, and SOX
audits in a modern fintech company with a card storage environment and
massive cash flows to account for and safeguard, my professional opinion as
someone on the information security team for that company is that the net
effect of ESNI on any of the compliance strategies being used is 0.

I think you might get a different perspective from someone whose compliance
strategy is largely predicated on e.g. Blue Coat "Visibility" appliances
who think things like passive SNI inspection are good indicators that
traffic flows are legitimate. However, while I'm aware this approach is
quite popular with e.g. older financial institutions, as noted above with
the S3 example it's still leaky. As long as you have a "legitimate"
frontend that can reach a backend which will honor the Host header over
what's in SNI and can get to both "legitimate" and attacker-controlled
resources, attackers can already bypass things passive SNI inspection.

That said, I think there are very much legitimate enterprise use cases of
this feature (see below).


> If we continue down these paths, then I fear networks will be required to
> wrap all traffic in some other less secure protocol, outright deny some of
> these protocols, or be forced to fully proxy all traffic or take an
> approach that Google has done with their BeyondCorp design.
>

In my opinion BeyondCorp-style designs are considered state-of-the-art by
the security teams of companies I respect, including the public fintech
company I formerly worked at which is presently in the process of migrating
from VPN-based access to a BeyondCorp-style approach.

As someone presently solving this problem for my company, I have recently
deployed Google's Identity Aware Proxy (IAP) to provide "front door"
authentication to internal web applications. IAP works by having you point
DNS at Google's frontend web servers, which terminate HTTPS, check for a
credential, and if it isn't present perform an OAuth flow. It integrates
with the rest of Google's suite of "BeyondCorp" tools including things like
Cloud Identity and Endpoint Verification to ensure all access to internal
tools is both strongly authenticated and coming from a known healthy
endpoint.

The important point here is that everyone using IAP is pointing DNS at the
Google frontend. In conjunction with e.g. Google Domains or GCP Cloud DNS,
IAP could support this approach to ESNI. In a BeyondCorp architecture, ESNI
would provide confidentiality for the DNS names of internal tools being
accessed through IAP. Using something like DoH in conjunction with
dns.google.com, we can completely reduce the parties who are able to
determine which

Re: [TLS] [PSA] 0-RTT tolerance is mandatory

[Eric Rescorla]

On Wed, Jul 4, 2018 at 6:27 AM, Hubert Kario  wrote:

> On Wednesday, 4 July 2018 15:06:27 CEST Ilari Liusvaara wrote:
> > On Wed, Jul 04, 2018 at 02:42:51PM +0200, Hubert Kario wrote:
> > > All the implementations I deal with in my day-to-day work fail to
> handle
> > > the 0-RTT client hello correctly when the 0-RTT support is not enabled
> on
> > > the server.
> > >
> > > I.e. they ignore the MUST clause from
> > > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating
> that
> > > the server can handle an early_data extension (and following encrypted
> > > data) in only one of three ways, neither which allows for unconditional
> > > connection abort.
> > >
> > > This also runs afoul the recommendation from
> https://tools.ietf.org/html/
> > > draft-ietf-tls-tls13-28#section-D.3 on 0-RTT backwards compatibility.
> >
> > OTOH, such servers probably do not send out tickets allowing 0-RTT, so
> > any client attempting 0-RTT with such server is very broken.
>
> please read Section D.3, it is spelled out in detail there why that's not
> the
> case
>
>
> the short of it: the client has no way of knowing if it is connecting to
> the
> same server/instance/process it received the ticket from
>

That's true if you have some kind of mixed rollout, but if you never
supported
0-RTT, then there is something wrong with the client.

-Ekr


> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
>
> ___
> 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] DNS-based Encrypted SNI

[Eric Rescorla]

On Wed, Jul 4, 2018 at 6:08 AM, Ilari Liusvaara 
wrote:

> On Wed, Jul 04, 2018 at 05:56:07AM -0700, Eric Rescorla wrote:
> > On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:=
> > > > I am working on an implementation for NSS/Firefox and I know some
> > > > others are working on their own implementations, so hopefully we can
> > > > do some interop in Montreal.
> > > >
> > > > This is at a pretty early stage, so comments, questions, defect
> > > > reports welcome.
> > >
> > > One thing I noticed: First there is this in evaluation:
> > >
> > > 7.2.4.  Do not stick out
> > >
> > >By sending SNI and ESNI values (with illegitimate digests), or by
> > >sending legitimate ESNI values for and "fake" SNI values, clients do
> > >not display clear signals of ESNI intent to passive eavesdroppers.
> > >
> > > Is that suggesting to send fake ESNI values? If so, there is this in
> > > endpoint behavior:
> > >
> >
> > No, you would not send fake ESNI values. The idea here is that there is a
> > group of IPs (associated with a big provider, then all ESNI-supporting
> > clients will send ESNI to it. So the provider will stick out, but the use
> > of site X versus site Y on the provider will notstick out. And the
> > provider's IPs are reasonably well known through other mechanisms, so
> this
> > doesn't tell you much. Of course, this does not help big sites that
> aren't
> > using shared infrastructure (e.g., Facebook), but I don't know how to do
> > that.
>
> What does "with illegitimate digests" mean then?
>

I didn't write this text, but I agree that it's in conflict with the
requirement that
you abort with an unknown key. We went through some design variants and
this looks like a remnant of a previous one.

-Ekr


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

Re: [TLS] Malformed Finished handling

[Eric Rescorla]

On Wed, Jul 4, 2018 at 6:36 AM, Hubert Kario  wrote:

> On Wednesday, 4 July 2018 15:00:18 CEST Eric Rescorla wrote:
> > I think it's a close call, because the length is sort of external to the
> > language.
>
> which language? the decode_error alert description literally says "length
> of
> the message was incorrect."
>

The protocol definition language.

-Ekr


> > That's why, for instance, NSS sends "illegal_parameter". So,
> > absent specific text about this value, I think this is something we can
> > leave to the implementations.
>
> but the text is explicit, if a message continues past message boundary,
> the
> correct response is decode_error. Decode_error is also consistent with the
> way
> above-expected length Client Hello MUST be handled.
>
> Just because the description of the message uses a single opaque array
> doesn't
> make this message syntactically any different from other Handshake
> protocol
> message.
>
> if the interpretation of "I know this _message_ _length_ is wrong because
> of
> some other values I negotiated before, so I'll send illegal_parameter" was
> correct, then overflow_error, decrypt_error and probably few others would
> also
> need to be replaced with illegal_parameter...
>
> > -Ekr
> >
> > On Wed, Jul 4, 2018 at 2:54 AM, Hubert Kario  wrote:
> > > Despite this, is it correct to terminate a connection with
> > > "illegal_parameter"
> > > upon receiving a Finished handshake message with a 100 byte payload?
> or a
> > > 20
> > > byte payload? My opinion is that it is not, "decode_error" is more
> > > specific so
> > > it should be used instead.
> > >
> > >
> > > Specification says the following on the matter:
> > >
> > > The draft 28 specifies the Finished message as having following
> structure:
> > >   struct {
> > >
> > >   opaque verify_data[Hash.length];
> > >
> > >   } Finished;
> > >
> > > At multiple places it also talks about handling messages that have
> sizes
> > > that
> > > don't match their structure as requiring termination of connection with
> > > "decode_error".
> > >
> > > The generic situation in Section 6:
> > >Peers which receive a message which
> > >cannot be parsed according to the syntax (e.g., have a length
> > >extending beyond the message boundary or contain an out-of-range
> > >length) MUST terminate the connection with a "decode_error" alert.
> > >
> > > as description of the alert in Section 6.2:
> > >decode_error  A message could not be decoded because some field was
> > >
> > >   out of the specified range or the length of the message was
> > >   incorrect.  This alert is used for errors where the message does
> > >   not conform to the formal protocol syntax.
> > >
> > > In specific about Client Hello, in Section 4.1.2:
> > >If negotiating a version of TLS prior to 1.3, a server MUST check
> > >that the message either contains no data after
> > >legacy_compression_methods or that it contains a valid extensions
> > >block with no data following.  If not, then it MUST abort the
> > >handshake with a "decode_error" alert.
> > >
> > > And specific handling of Certificate from server in Section 4.4.2.4:
> > >If the server supplies an empty Certificate message, the client MUST
> > >abort the handshake with a "decode_error" alert.
> > >
> > > Description of "illegal_parameter" in Section 6:
> > >Peers which receive a message which is syntactically correct but
> > >semantically invalid (e.g., a DHE share of p - 1, or an invalid
> enum)
> > >MUST terminate the connection with an "illegal_parameter" alert.
> > >
> > > Alert description in Section 6.2:
> > >illegal_parameter  A field in the handshake was incorrect or
> > >
> > >   inconsistent with other fields.  This alert is used for errors
> > >   which conform to the formal protocol syntax but are otherwise
> > >   incorrect.
> > >
> > > (it's also mentioned in over a dozen places in the draft)
> > > --
> > > Regards,
> > > Hubert Kario
> > > Senior Quality Engineer, QE BaseOS Security team
> > > Web: www.cz.redhat.com
> > > Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
> > > ___
> > > TLS mailing list
> > > TLS@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tls
>
>
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DNS-based Encrypted SNI

[Eric Rescorla]

Stephen,

Thanks for your comments.

On Wed, Jul 4, 2018 at 6:01 AM, Stephen Farrell 
wrote:

>
> Hiya,
>
> On 03/07/18 00:39, Eric Rescorla wrote:
> > Hi folks,
> >
> > I just submitted:
> >
> >   https://tools.ietf.org/html/draft-rescorla-tls-esni-00
>
> Thanks for writing that up. I think it's an interesting
> addition to the set of potential solutions.
>
> >
> > This draft describes a DNS-based approach to doing encrypted SNI.
> >
> > Previously, we had thought this wouldn't work because only sites that
> > were particularly vulnerable would do it, and so the use of ESNI marks
> > you out. The idea behind this draft is that there are a lot of sites
> > which are hosted by -- and whose DNS is run by -- a large provider,
> > and that provider can shift many if not all of its sites to ESNI at
> > once, thus removing the "standing out" issue and making a DNS-based
> > approach practical.
>
> I'm not sure I fully understand how this approach would fit
> with others, nor to what extent it depends on the DNS and
> CDN providers co-operating, but it definitely seems worth
> exploring.
>

I think the answer is "a lot". Basically, the entire reasoning here is that
you can convert a lot of people at once. If you can't, then I don't think
this is a viable option.



- I didn't quite get what "all the domains" in 3.2 means. I
> guess if a client uses non-encrypted sni for one of those,
> it should still work, but I'm not clear if supporting esni
> for any domain means that the provider has to decrypt esni
> and then deal with successful decrypted sni values as if
> the client had sent sni in clear. A concern is requiring
> "all the domains" might make it hard to roll this out.
>

Yeah, this is badly written. It just means "all the ESNI-supporting
domains". But as I said, if you host 50 domains and you only
turn on ESNI for one, it's kind of pointless.



- I guess some form(s) of key rollover will be needed, ut
> I'm not sure that not_before/not_after is the best way to
> do that.
>

> - The ESNIKeys structure generally seems a bit complicated,
> it might be better to aim for simplifying that and maybe
> making it more "zonefile friendly" (whether in a TXT RR
> or not).
>

The structure started a bit simpler and got new features to
deal with new issues. Specifically:

- The checksum is intended to deal with corruption
- The keys and cipher suites seem kind of mandatory
- The padded length is needed to tell the client how much to
  pad. Though I guess we could always pad to 260. If you don't
  pad at all, it doesn't work.
- I think it's clear what not_before and not_after are for. If you have
  more concrete feedback about better ways to do that, we'd welcome
  this.
- Extensions is just there because we're trying to be safe.

FWIW, this actually is pretty friendly because we b64-encode
(thus making the internal structure opaque to DNS). Removing
things won't make it much smaller because a big chunk of
the data is in the keys. For instance, in my implementation,
the object is 70 bytes long and 34 bytes of that is key (X25519)
and 8 bytes is cipher suite (each of these has 2 bytes of length).




- It might be interesting to think about how this'd work
> for e.g. the IETF web site (where ietf.org is hosted
> locally but www.ietf.org is not), and for STARTTLS and
> MX RRs. That's probably ok, but I've not gotten it
> straight in my little head yet:-)
>

I don't think we're assuming it applies to subdomains.



> - Would it make sense to include the innocuous dummy sni
> in the published RR, so that all clients use the same
> one and stand out that bit less?
>

We actually had an "alt-svc" thing in here for that and removed
it at the last minute. I'd welcome input on the best thing here.



> - 7.1 probably needs more work -


The whole draft needs more work!


I'm not sure that it's
> that ok to use this with cleartext DNS. ISTM that DOH/DPRIVE,
> or a client application that knows the ESNIKeys, are most
> likely needed, but there's probably also some work to do
> to analyse the recursive to authoritative interactions to
> get the ESNIKeys even with DPRIVE.
>

"OK" might not have been the best choice of words. I think this actually
contains two arguments:

1. You don't need DNSSEC.
2. It doesn't make matters worse to do this over unencrypted DNS (i.e.,
you're already
in trouble).

That said, it also doesn't add much value to do ESNI if the attacker
controls your DNS, and in Firefox we're looking initially at just doing it
when DoH is in use.



Lastly, the topic of whether or not to try address this
> problem is something that the WG has debated quite a bit,
> and IIRC the consensus after that debate was to do work
> on this (hence Christian's draft).
>

Thanks for making this point. My understanding was that we had WG consensus
to protect SNI. Of course, it may be the case that the WG doesn't like this
solution for one reason or another -- including potentially that it has an
especially bad impact on enterprise deplo

Re: [TLS] DNS-based Encrypted SNI

[Stephen Farrell]

Hiya,

Just on this bit...

On 04/07/18 18:20, Eric Rescorla wrote:
> The structure started a bit simpler and got new features to
> deal with new issues. Specifically:
> 
> - The checksum is intended to deal with corruption

I'm not sure I see why that's needed, but I believe you if
you say it might help with some home routers. (Though I'd
also be interested in information/citation about the
details of the problems seen there.)

> - The keys and cipher suites seem kind of mandatory

Yep. OTOH, given we need to support >1 value for the RR, if
mostly people just need one key+CS per-RR, it may be possible
to use multiple RRs to provide additional keys/CSes. (If most
uses would have a variable number of keys/CSes then I agree
the current structure is better.)

> - The padded length is needed to tell the client how much to
>   pad. Though I guess we could always pad to 260. If you don't
>   pad at all, it doesn't work.

Sure.

> - I think it's clear what not_before and not_after are for. If you have
>   more concrete feedback about better ways to do that, we'd welcome
>   this.

With not_before/not_after (and the TTL) there'll need to be some
consideration of the various overlaps, which has been a source of
bugs and ops screw-ups in other scenarios. I also don't like the
forced expiry of not_after - people will just put in 2038 all over,
or risk weird breakage. (X.509's mandatory notAfter was IMO an
error for most uses of X.509 - an error inherited from the X.500
DAP user authentication use-case that initially motivated X.509.)

I wonder would an incrementing counter (like SOA serial) maybe be
easier where the client just uses the highest value? (There was
some discussion on related topics during the work on MTA-STS, but
I forget the details, might be worth checking with the folks
involved.)

> - Extensions is just there because we're trying to be safe.

Sure, but I hope we consider dropping 'em if there's no need.
New RRTYPEs could always be used for extensions (if new RRTYPEs
are cheap, that is:-)

> 
> FWIW, this actually is pretty friendly because we b64-encode
> (thus making the internal structure opaque to DNS). Removing
> things won't make it much smaller because a big chunk of
> the data is in the keys. For instance, in my implementation,
> the object is 70 bytes long and 34 bytes of that is key (X25519)
> and 8 bytes is cipher suite (each of these has 2 bytes of length).

That's good. But I was more thinking about how friendly this
would be for the DNS admin folks. One thing I like about TLSA
and CAA is that (for my use-cases:-) I can just cut'n'paste
the values into zone files and they'll be good until a CA root
key or name changes, which is pretty rare and would be widely
advertised ahead of time.

With RRSIGs and similar, I can also easily inspect values by
just looking at zonefiles and/or using dig, which is helpful
for me at least. But I don't have to deal with large zones so
that kind of inspection may not be of much use to larger
operators. So, I'd defer to real DNS server folks on whether
or not being able to directly view the internals of ESNIKeys
encoding makes any difference.

All that said, I did just suggest adding in the dummy sni
value:-) So I mostly think if this goes ahead (as I hope it
does), we spend a bit of time considering the above issues
before we're done.

Cheers,
S.



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] DNS-based Encrypted SNI

[Kathleen Moriarty]

Sent from my mobile device

> On Jul 4, 2018, at 9:01 AM, Stephen Farrell  wrote:
> 
> 
> Hiya,
> 
>> On 03/07/18 00:39, Eric Rescorla wrote:
>> Hi folks,
>> 
>> I just submitted:
>> 
>>  https://tools.ietf.org/html/draft-rescorla-tls-esni-00
> 
> Thanks for writing that up. I think it's an interesting
> addition to the set of potential solutions.
> 
>> 
>> This draft describes a DNS-based approach to doing encrypted SNI.
>> 
>> Previously, we had thought this wouldn't work because only sites that
>> were particularly vulnerable would do it, and so the use of ESNI marks
>> you out. The idea behind this draft is that there are a lot of sites
>> which are hosted by -- and whose DNS is run by -- a large provider,
>> and that provider can shift many if not all of its sites to ESNI at
>> once, thus removing the "standing out" issue and making a DNS-based
>> approach practical.
> 
> I'm not sure I fully understand how this approach would fit
> with others, nor to what extent it depends on the DNS and
> CDN providers co-operating, but it definitely seems worth
> exploring.
> 
>> 
>> I am working on an implementation for NSS/Firefox and I know some
>> others are working on their own implementations, so hopefully we can
>> do some interop in Montreal.
>> 
>> This is at a pretty early stage, so comments, questions, defect
>> reports welcome.
> 
> Quick comments after flicking through the draft:
> 
> - I'm not that fussed myself as to whether this uses a TXT
> or new RRTYPE. But if the latter would work, it seems better.
> 
> - I didn't quite get what "all the domains" in 3.2 means. I
> guess if a client uses non-encrypted sni for one of those,
> it should still work, but I'm not clear if supporting esni
> for any domain means that the provider has to decrypt esni
> and then deal with successful decrypted sni values as if
> the client had sent sni in clear. A concern is requiring
> "all the domains" might make it hard to roll this out.
> 
> - I guess some form(s) of key rollover will be needed, ut
> I'm not sure that not_before/not_after is the best way to
> do that.
> 
> - The ESNIKeys structure generally seems a bit complicated,
> it might be better to aim for simplifying that and maybe
> making it more "zonefile friendly" (whether in a TXT RR
> or not).
> 
> - It might be interesting to think about how this'd work
> for e.g. the IETF web site (where ietf.org is hosted
> locally but www.ietf.org is not), and for STARTTLS and
> MX RRs. That's probably ok, but I've not gotten it
> straight in my little head yet:-)
> 
> - Would it make sense to include the innocuous dummy sni
> in the published RR, so that all clients use the same
> one and stand out that bit less?
> 
> - 7.1 probably needs more work - I'm not sure that it's
> that ok to use this with cleartext DNS. ISTM that DOH/DPRIVE,
> or a client application that knows the ESNIKeys, are most
> likely needed, but there's probably also some work to do
> to analyse the recursive to authoritative interactions to
> get the ESNIKeys even with DPRIVE.
> 
> Lastly, the topic of whether or not to try address this
> problem is something that the WG has debated quite a bit,
> and IIRC the consensus after that debate was to do work
> on this (hence Christian's draft).
> 
> So I don't see any need to debate whether or not to work on
> this is needed, and trying to re-open such a debate seems
> somewhat disruptive to me. It is entirely reasonable to
> consider what, if anything, widespread use of esni or other
> approaches might break though. But going back to all this
> "privacy at any cost" and "we're the enterprises" hyperbole
> is not at all helpful IMO, so I hope we don't have to suffer
> more rounds of that. But maybe that's inevitable with every
> iteration of attempts to improve privacy sadly;-(

I’m also fine with the work going forward, however it was only in March that 
EKR assured people concerned that they don’t need to worry about SNI being 
encrypted repeating similar statements previously made to the same effect.  
Meantime, he was working on such a solution.  People need warning to prepare 
for changes, not to be surprised by them after being told not to worry.  They 
may not have had a chance to think through how they might adapt.

Kathleen 

> 
> Cheers,
> S.
> 
> 
>> 
>> -Ekr
>> 
>> 
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> 
> <0x5AB2FAF17B172BEA.asc>
> ___
> 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] DNS-based Encrypted SNI

[Eric Rescorla]

Hi Kathleen,

On Wed, Jul 4, 2018 at 11:10 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> I’m also fine with the work going forward, however it was only in March
> that EKR assured people concerned that they don’t need to worry about SNI
> being encrypted repeating similar statements previously made to the same
> effect.  Meantime, he was working on such a solution.


This is not really correct. As of March, I had basically given up on how to
do ESNI in TLS the near future and wasn't really working on it [0] and then
in May, prompted by suggestions by Matthew Prince and Nick Sullivan, I
realized that the proposal in this document could work.

Moreover, I think I've been pretty clear that I wanted to do ESNI and it
was just that we didn't know how. For instance, here's what I said in
PATIENT:

   My evaluation of the current state of SNI encryption is that given the
   current technical state, it will not see particularly wide deployment,
with
   the primary scenario being "at-risk" sites who are subject to censorship
who
   either hide behind or co-tenant with sites which are not subject to
   censorship. That probably isn't going to be incredibly common right now.
Of
   course, this is regrettable from the perspective of people designing
these
   protocols, but I think that's the situation.

As I said the other day, predictions are hard, especially about the future,
and this turns out not to have been totally right (though I also don't
think it's really accurate to characterize it as my saying that people
don't need to worry). I'm sorry if people people are surprised now. That
wasn't my intent, but as I said above, I was surprised too!

-Ekr

[0] Just to be completely clear, there was and is ongoing work on
protecting SNI via HTTP connection coalescence (see Mike Bishop's
presentation in London), but that's a different flavor of approach, and
it's not like it's any secret it's happening.




> Kathleen
>
> >
> > Cheers,
> > S.
> >
> >
> >>
> >> -Ekr
> >>
> >>
> >>
> >> ___
> >> TLS mailing list
> >> TLS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> >>
> > <0x5AB2FAF17B172BEA.asc>
> > ___
> > 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] DNS-based Encrypted SNI

[Eric Rescorla]

On Wed, Jul 4, 2018 at 11:07 AM, Stephen Farrell 
wrote:

>
> Hiya,
>
> Just on this bit...
>
> On 04/07/18 18:20, Eric Rescorla wrote:
> > The structure started a bit simpler and got new features to
> > deal with new issues. Specifically:
> >
> > - The checksum is intended to deal with corruption
>
> I'm not sure I see why that's needed, but I believe you if
> you say it might help with some home routers. (Though I'd
> also be interested in information/citation about the
> details of the problems seen there.)
>

Sure. that's a fair question. Kazuho proposed this, so I'd be interested in
his view.

>
> > - The keys and cipher suites seem kind of mandatory
>
> Yep. OTOH, given we need to support >1 value for the RR, if
> mostly people just need one key+CS per-RR, it may be possible
> to use multiple RRs to provide additional keys/CSes. (If most
> uses would have a variable number of keys/CSes then I agree
> the current structure is better.)
>

I think it's bad to provide multiple options that aren't coupled together.
Moreover, from the perspective of the TLS stack, it's actually easier
to have them all bundled.



> - I think it's clear what not_before and not_after are for. If you have
> >   more concrete feedback about better ways to do that, we'd welcome
> >   this.
>
> With not_before/not_after (and the TTL) there'll need to be some
> consideration of the various overlaps, which has been a source of
> bugs and ops screw-ups in other scenarios. I also don't like the
> forced expiry of not_after - people will just put in 2038 all over,
>

Note that this is 64 bits, so you can go far past 2038 :)


> - Extensions is just there because we're trying to be safe.
>
> Sure, but I hope we consider dropping 'em if there's no need.
> New RRTYPEs could always be used for extensions (if new RRTYPEs
> are cheap, that is:-)
>

I would not be in favor of this. It's trivial to parse and ignore.


> (thus making the internal structure opaque to DNS). Removing
> > things won't make it much smaller because a big chunk of
> > the data is in the keys. For instance, in my implementation,
> > the object is 70 bytes long and 34 bytes of that is key (X25519)
> > and 8 bytes is cipher suite (each of these has 2 bytes of length).
>
> That's good. But I was more thinking about how friendly this
> would be for the DNS admin folks. One thing I like about TLSA
> and CAA is that (for my use-cases:-) I can just cut'n'paste
> the values into zone files and they'll be good until a CA root
> key or name changes, which is pretty rare and would be widely
> advertised ahead of time.
>
> With RRSIGs and similar, I can also easily inspect values by
> just looking at zonefiles and/or using dig, which is helpful
> for me at least. But I don't have to deal with large zones so
> that kind of inspection may not be of much use to larger
> operators. So, I'd defer to real DNS server folks on whether
> or not being able to directly view the internals of ESNIKeys
> encoding makes any difference.
>
> All that said, I did just suggest adding in the dummy sni
> value:-) So I mostly think if this goes ahead (as I hope it
> does), we spend a bit of time considering the above issues
> before we're done.
>

Sure, that seems reasonable. I think you are getting to something
important here: my philosophy here is that this should be a more
or less opaque blob which you provide to the TLS stack. So I'm
optimizing for what's convenient for that. I can understand that
others might feel differently.

-Ekr


> Cheers,
> S.
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DNS-based Encrypted SNI

[Kathleen Moriarty]

Sent from my mobile device

> On Jul 4, 2018, at 2:20 PM, Eric Rescorla  wrote:
> 
> Hi Kathleen,
> 
>> On Wed, Jul 4, 2018 at 11:10 AM, Kathleen Moriarty 
>>  wrote:
>> I’m also fine with the work going forward, however it was only in March that 
>> EKR assured people concerned that they don’t need to worry about SNI being 
>> encrypted repeating similar statements previously made to the same effect.  
>> Meantime, he was working on such a solution. 
> 
> This is not really correct. As of March, I had basically given up on how to 
> do ESNI in TLS the near future and wasn't really working on it [0] and then 
> in May, prompted by suggestions by Matthew Prince and Nick Sullivan, I 
> realized that the proposal in this document could work.
> 
> Moreover, I think I've been pretty clear that I wanted to do ESNI and it was 
> just that we didn't know how. For instance, here's what I said in PATIENT:
> 
>My evaluation of the current state of SNI encryption is that given the
>current technical state, it will not see particularly wide deployment, with
>the primary scenario being "at-risk" sites who are subject to censorship 
> who
>either hide behind or co-tenant with sites which are not subject to
>censorship. That probably isn't going to be incredibly common right now.. 
> Of
>course, this is regrettable from the perspective of people designing these
>protocols, but I think that's the situation.
> 
> As I said the other day, predictions are hard, especially about the future, 
> and this turns out not to have been totally right (though I also don't think 
> it's really accurate to characterize it as my saying that people don't need 
> to worry). I'm sorry if people people are surprised now. That wasn't my 
> intent, but as I said above, I was surprised too!
> 

Well, the messages on the Effects of Pervasive Encryption for Operators also 
factored into my response.  You wanted that text removed and we refused 
(rightly so).  You also had someone write a blog to have a reference that 
talked about it’s wide deployment.  The perception is from multiple 
interactions and I favor transparency.

Best,
Kathleen 

> -Ekr
> 
> [0] Just to be completely clear, there was and is ongoing work on protecting 
> SNI via HTTP connection coalescence (see Mike Bishop's presentation in 
> London), but that's a different flavor of approach, and it's not like it's 
> any secret it's happening.
> 
> 
>  
>> Kathleen 
>> 
>> > 
>> > Cheers,
>> > S.
>> > 
>> > 
>> >> 
>> >> -Ekr
>> >> 
>> >> 
>> >> 
>> >> ___
>> >> TLS mailing list
>> >> TLS@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/tls
>> >> 
>> > <0x5AB2FAF17B172BEA.asc>
>> > ___
>> > 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] Malformed Finished handling

[Martin Thomson]

On Wed, Jul 4, 2018 at 7:55 PM Hubert Kario  wrote:
> Despite this, is it correct to terminate a connection with "illegal_parameter"
> upon receiving a Finished handshake message with a 100 byte payload? or a 20
> byte payload? My opinion is that it is not, "decode_error" is more specific so
> it should be used instead.

When there are multiple problems with a message, why do we need to
accept just one of the possible alerts?  That assumes either a very
particular order of processing, or a strict precedence order for
errors.  Like Rich says, there is a degree of imprecision in our error
reporting, but - for me - that's OK.

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

Re: [TLS] DNS-based Encrypted SNI

[Kazuho Oku]

2018-07-05 3:23 GMT+09:00 Eric Rescorla :
>
>
> On Wed, Jul 4, 2018 at 11:07 AM, Stephen Farrell 
> wrote:
>>
>>
>> Hiya,
>>
>> Just on this bit...
>>
>> On 04/07/18 18:20, Eric Rescorla wrote:
>> > The structure started a bit simpler and got new features to
>> > deal with new issues. Specifically:
>> >
>> > - The checksum is intended to deal with corruption
>>
>> I'm not sure I see why that's needed, but I believe you if
>> you say it might help with some home routers. (Though I'd
>> also be interested in information/citation about the
>> details of the problems seen there.)
>
>
> Sure. that's a fair question. Kazuho proposed this, so I'd be interested in
> his view.

IMO, when used, ESNIKeys is part of the handshake, and therefore
deserves (at least) the same level of end-to-end integrity protection
as what is provided by TCP.

ESNIKeys becomes part of the handshake in the following sense:

* a corrupt ESNIKeys will cause the handshake to fail
* ENSIKeys is used to negotiate the use of a TLS extension
* the value of ESNIKeys is part of the handshake transcript though
`EncryptedSNI.record_digest` which is a full digest of ESNIKeys, much
like the 1st CH when HRR is involved

TLS records (even the non-encrypted ones) are resistant to accidental
corruption thanks to the integrity check provided by TCP. OTOH,
ESNIKeys is transmitted though DNS authoritative server (by setting up
the DNS record either automatically or by hand), then a recursive
resolver, then a stub resolver, before reaching the client.

As Stephen says, some resolvers (e.g. home routers) could be the
source of corruption of DNS records. But even if we bypass them by
using DoH or DNS over TLS, the lack of end-to-end integrity check will
still be an issue. Corruption could for example happen when the record
is installed to the authoritative server, or when they are stored (or
cached) within the resolvers.

Considering the varying degree of the reliability provided by the
multiple parties involved in forwarding the ESNIKeys as DNS records,
my perception has been that it is a good idea to have end-to-end
integrity protection.

>> > - The keys and cipher suites seem kind of mandatory
>>
>> Yep. OTOH, given we need to support >1 value for the RR, if
>> mostly people just need one key+CS per-RR, it may be possible
>> to use multiple RRs to provide additional keys/CSes. (If most
>> uses would have a variable number of keys/CSes then I agree
>> the current structure is better.)
>
>
> I think it's bad to provide multiple options that aren't coupled together.
> Moreover, from the perspective of the TLS stack, it's actually easier
> to have them all bundled.

I also prefer them to be bundled, because it makes us easier and
faster to detect downgrade attacks.

Current draft uses a full digest of ENSIKeys (i.e.
`EncryptedSNI.record_digest`) to identify the ESNIKeys being used. If
a middlebox drops some key-share from ESNIKeys, the server will fail
to identify the ESNIKeys being used, and the handshake fails. This
would be the case even when DNSSEC is _not_ used.

If we use different DNS record for every key-share being negotiated,
the client will be required to wait for the response of all the
queries it has sent (more likely to suffer from delays), and there
will be no protection against a downgrade attack when DNSSEC is not
used.

>> > - I think it's clear what not_before and not_after are for. If you have
>> >   more concrete feedback about better ways to do that, we'd welcome
>> >   this.
>>
>> With not_before/not_after (and the TTL) there'll need to be some
>> consideration of the various overlaps, which has been a source of
>> bugs and ops screw-ups in other scenarios. I also don't like the
>> forced expiry of not_after - people will just put in 2038 all over,
>
>
> Note that this is 64 bits, so you can go far past 2038 :)

FWIW, the intent of having not_after in the draft is to avoid issues
when a DNS authoritative server and the TLS server (i.e. the entity
that generates the ESNIKeys) get out-of-sync [1].

When the TLS server rotates the ESNIKeys (which should happen
frequently), it needs to make sure that all the authoritative servers
receive the update. If that attempt fails, we'd rather fallback to
plaintext SNI rather than seeing handshake failures. Minimizing (or
nullifying) the increased chance of seeing handshake failures is
important for ESNI, because we want as many domains as possible (even
those that are not strongly interested in having their SNI protected)
to participate in the effort; otherwise, the domains using ESNI will
"stick out" [2].

However, DNS as a standard does not provide a way to set absolute
expiration dates. Not only the responses to queries but also AFXR
carries only the TTL. Therefore, an out-of-sync authoritative server
will continue to respond with the outdated ESNIKeys. The fact makes it
harder for server administrators to manage the keys.

To summarize, what we want is consistency (stop sending valid ESNIKeys
when

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Eric Rescorla]

On Mon, Jun 25, 2018 at 9:20 PM, Joseph Salowey  wrote:

> Hi Folks,
>
> There has been some discussion with a small group of folks on github -
> https://github.com/tlswg/dnssec-chain-extension/pull/19.   I want to make
> sure there is consensus in the working group to take on the pinning work
> and see if there is consensus for modifications in the revision.  Please
> respond to the following questions on the list by July 10, 2018.
>
> 1.  Do you support the working group taking on future work on a pinning
> mechanism (based on the modifications or another approach)?
>

Unsure. I'd like to see some real evidence that it will be widely consumed.
Do we have a count of major implementors who say they will do so?


2.  Do you support the reserved bytes in the revision for a future pinning
> mechanism?
>

No. I'm undecided on whether we should have an extension point here, but
I'm strongly against having it just be opaque reserved bytes. Everywhere
else we have decided to put extension points, we've had them as Extensions,
not just "here are some bytes".  Aside from this being general TLS
practice, it is good futureproofing because one can grease Extensions,
whereas you cannot grease opaque bytes.


3.  Do you support the proof of denial of existence text in the revision?
>

The mechanism seems fine, but it doesn't seem to me that the specification
is clear on what the semantics are. I think what they are is that you can
configure the client to be in some "DNSSEC required" mode which will
requires that the extension be returned and that it either (a) contain
DNSSEC-signed records for the domain or (b) contain authenticated denial of
existence. Is this correct? If so, I would be happy to have the text merged
and then wordsmith this explanation.


4.  Do you support the new and improved security considerations?
>

They seem like a good start. I'd be happy to have them merged and wordsmith
them.

-Ekr


> Thanks,
>
> Joe
>
>
>
> On Tue, Jun 5, 2018 at 6:51 AM, Paul Wouters  wrote:
>
>> On Mon, 4 Jun 2018, Benjamin Kaduk wrote:
>>
>> Hi Ben,
>>
>> I've taken a stab at putting together some security considerations text
>>> for
>>> draft-ietf-tls-dnssec-chain-extension that reflects my understanding of
>>> the
>>> current state of affairs.  It's in a pull request at
>>> https://github.com/tlswg/dnssec-chain-extension/pull/19 , along with
>>> Viktor's
>>> commit to update the text about the actual DNS records involved (which as
>>> far as I can tell seems to improve the technical accuracy of the text),
>>> and
>>> also inserting a variable-length array that's reserved for future
>>> attempts
>>> to mitigate the (now-)documented security considerations.
>>>
>>
>> Thanks for writing the proposed text. The new opaque Reserved field
>> along with the denial of existence changes you propose addresses all
>> my concerns.
>>
>> One corner case that might be worth mentioning with the proposed DoE text
>> is the odd corner case of hitting a server with a Host header for which
>> it is not configured. You will hit the "default vhost" but you have no
>> appropriate extension data to populate for that hostname. So either the
>> server will return the (cached) TLSA/DoA data of the 'wrong' hostname,
>> or it could just omit the extension. I'd mostly like to say something to
>> prevent an implementation of forgetting this corner case and causing
>> some vulnerability in their code later on by pointing to bogus memory or
>> crashing on dereferencing a NULL.
>>
>> Some nits:
>>
>> If the server supports this extension it performs the appropriate
>> DNS queries,
>>
>> In my PR I had changed this into "obtains the appropriate DNS RRsets",
>> because I envision that TLS servers might not do DNS lookups themselves,
>> but just read this via a file or other method. Eg a cron job that
>> regenerates these hourly for all the hosted domains. It also reduces
>> some fear that all TLS servers suddenly could need to link against
>> a DNSSEC library. They don't if they can just reload a blob from disk
>> regularly to serve up.
>>
>> Similarly:
>>
>> it will need to rebuild
>>
>> is better written as "it will need rebuilt data"
>>
>>
>> "authenticates the chain"
>>
>> That should probably be "validate the chain", but the document has more
>> mixups of validate vs authenticate. In my PR request I had not corrected
>> them in an effort to keep the diff as small as possible.
>>
>> I had modified the examples slightly, so the NSEC example would show a
>> simpler NSEC chain (from www to zzz) instead of the one wrapping around
>> from www to the zone apex. The example quoted is the wrong NSEC record
>> (the one from apex to www.example.com does not show that the
>> _443._tcp.www.example.com does not exist, you need the one from
>> www..example.com  to the apex at the end of the
>> zone)
>>
>>
>> I'm not sure what you mean with:
>>
>> validated negative TTL
>>
>> I guess you mean to say the shortes

Re: [TLS] Broken browser behaviour with SCADA TLS

[Peter Gutmann]

Ilari Liusvaara  writes:

>Chrome initially did that. It caused quite a lot of bad feedback from owners
>of various bad embedded stuff. The thread on relevant forums was quite
>something. Hundreds of messages blaming Google for breaking stuff.

If there were "hundreds of messages" doesn't that indicate that it's Chrome
that's the problem, and not everyone else?

Peter.

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

Re: [TLS] Broken browser behaviour with SCADA TLS

[Peter Gutmann]

Kurt Roeckx  writes:

>The extensions are not related to TLS, but are extentions / add-ons of the
>browser itself. Firefox dropped support for the old way of doing extensions
>in version 57. They also added the WebExtensions API that is also implemented
>in other browsers. This required major rewrites of the extensions, and some
>were never changed to work with the new API.

As I understand it (E&OE), the flow was that a bunch of SCADA stuff used
browser extensions, presumably to talk things like IEC 61850.  When the
existing extensions broke, there was a general exodus from Firefox to Chrome,
however when Chrome broke at the TLS level there was indecision about what to
do.  There are also IE plugins, I assume the advice going forwards will be to
use IE.

(I have no idea about the prevalence of IE vs. others, but since it's the
default browser for Windows I assume this will be the easiest/recommended path
fowards, and until Windows 10 MS had a long history of being excruciatingly
careful about backwards compatibility so it seems the safest bet).

Peter.

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Viktor Dukhovni]

On Wed, Jul 04, 2018 at 06:34:44PM -0700, Eric Rescorla wrote:

> 3.  Do you support the proof of denial of existence text in the revision?
> 
> The mechanism seems fine, but it doesn't seem to me that the specification
> is clear on what the semantics are. I think what they are is that you can
> configure the client to be in some "DNSSEC required" mode which will
> requires that the extension be returned and that it either (a) contain
> DNSSEC-signed records for the domain or (b) contain authenticated denial of
> existence. Is this correct? If so, I would be happy to have the text merged
> and then wordsmith this explanation.

More precisely, you can configure the client to require the extension,
and yet still interoperate with servers that (support the extension,
but) live in an unsigned zone, or live in a signed zone with no
TLSA records for the service in question.  The server just needs
to be able to return a denial of existence proof for the DS records
of a delegated containing domain or its TLSA records, respectively.

Agree that merging the text for further polish is a logical next step. 

> 4.  Do you support the new and improved security considerations?
> 
> They seem like a good start. I'd be happy to have them merged and wordsmith
> them.

Ditto.

-- 
Viktor.

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Martin Thomson]

On Tue, Jun 26, 2018 at 2:21 PM Joseph Salowey  wrote:
> 1.  Do you support the working group taking on future work on a pinning 
> mechanism (based on the modifications or another approach)?

I don't think that pinning is a good idea.  We've experience that
suggests that it's more of a footgun than a useful mechanism.  That
isn't to say that there isn't a domain where it makes sense.

> 2.  Do you support the reserved bytes in the revision for a future pinning 
> mechanism?

No.  We need fewer extension points, not more.  It's already hard
enough to ensure that the ones we have remain usable.  ekr's
suggestion to reduce the number of *types* of extension point would be
a compromise position here, but I don't think that's the best outcome.

If we mess this one up, we can make another extension, or use another
extension to fix it if that makes more sense.  Yes, that's messy, but
the above assessment supports the notion that we won't need v2.

> 3.  Do you support the proof of denial of existence text in the revision?

Allowing denial of existence in the extension is fine.  It somewhat
depends on having a prior expectation of having some form of DNSSEC
record there, which hits all the concerns above, so I'm not sure what
concrete value it provides.  I see no harm in allowing it though.

> 4.  Do you support the new and improved security considerations?

I have to confess, I had a lot of trouble reading the new text.  It's
good, and contains much of what is needed, but it's very wordy.  I
think another iteration or two would help.

If I can summarize:

We consider the case where DANE is considered stronger than PKIX or a
valuable addition to PKIX, because this extension is only of use in
those circumstances.  If an attacker can compromise PKIX, then they
can just not send the DANE extension.  With prior knowledge, a relying
party might know to expect DANE, but that isn't always possible,
especially when this mechanism is introduced into a PKIX-only
ecosystem.  A relying party can't assume that use of DANE with one
connection implies that other connections to the same peer will also
be secured with DANE.

There's a lot of extra words around that message, and I fear that the
message will be lost as a result.

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

Re: [TLS] Broken browser behaviour with SCADA TLS

[Peter Gutmann]

David Benjamin ​ writes:

>The bad feedback was not even at a 2048-bit minimum, but a mere 1024-bit
>minimum. (Chrome enabled far more DHE ciphers than others, so we encountered
>a lot of this.) 2048-bit was completely hopeless. At the time of removal, 95%
>of DHE negotiations made by Chrome used a 1024-bit minimum.

How does Google, rather than the people running the systems being connected
to, know that 1024-bit DH isn't secure enough for a given environment?  The
majority of this stuff is running on isolated, private networks or inside VPN
tunnels for which pretty much anything, including 512-bit keys, are fine.

It's also somewhat disturbing that Chrome now walks straight past a perfectly
good PFS DHE suite and instead goes to a problematic pure-RSA one instead.

>You should instruct these folks to configure ECDHE+RSA ciphers if they have
>RSA keys. 

The devices don't do ECDHE, and they probably never will (at least until the
next upgrade cycle, which could take a decade or more), so there's nothing to
configure.

>rfc7919, did not fix the problem. This was pointed out here, but never
>incorporated to the document:

Yep.  The issues were pointed out by several people before it was published,
but got published anyway... with the result being that a number of
implementations chose not to support it because of the problems that it
causes.

>Particularly in the second scenario, it seems they're already implemented,
>just the server was incorrectly configured to use the wrong ones.

That was in my testing, not using a PLC control centre or similar, in other
words the actual devices being used in the field.  Doing that would have
required a firmware reload for each test, which is way too painful to think
about.  For "server incorrectly configured", see above, they were offering all
the suites the firmware and hardware supported.

Peter.


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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Viktor Dukhovni]

On Wed, Jul 04, 2018 at 06:34:44PM -0700, Eric Rescorla wrote:

> > 1.  Do you support the working group taking on future work on a pinning
> > mechanism (based on the modifications or another approach)?
> 
> Unsure. I'd like to see some real evidence that it will be widely consumed.
> Do we have a count of major implementors who say they will do so?

Well, what is a "major implementation"?  TLS is not just browsers,
and adoption does not always begin the day the RFC is published.
DANE adoption only started 2+ years after RFC6698, and is still
ramping up.  The important thing here is to not *preclude* adoption
by needlessly limiting the scope to just "greenfield" applications.

It is rather clear that the present draft is only compatible with
applications that mandate the extension.  Some form of "STS-lite"
pinning is needed to support incremental adoption by existing
applications.

> 2.  Do you support the reserved bytes in the revision for a future pinning
> > mechanism?
> 
> No. I'm undecided on whether we should have an extension point here, but
> I'm strongly against having it just be opaque reserved bytes. Everywhere
> else we have decided to put extension points, we've had them as Extensions,
> not just "here are some bytes".  Aside from this being general TLS
> practice, it is good futureproofing because one can grease Extensions,
> whereas you cannot grease opaque bytes.

It is far from clear why "grease" is applicable here, or what "grease
barriers" either proposed form of the reserved field presents.

* With the 16-bit field, servers set it to zero until non-zero
  values are specified.

* With the <0..255> byte value, servers send an empty value
  until non-empty values are specified.

* In either case clients ignore either non-zero or non-empty
  values, until they implement the specification, and must not
  employ pinning until such time.

I thought the authors wanted this done quickly, but lately they
seem to be in no rush to get the document finished.  If we're no
longer in a hurry to get this out the door before all the issues
are sorted out, we can specify the downgrade protection now, in
which case there's no need for reserved fields, we can define the
pinning approach now.

-- 
Viktor.

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Viktor Dukhovni]

On Thu, Jul 05, 2018 at 12:31:02PM +1000, Martin Thomson wrote:
> On Tue, Jun 26, 2018 at 2:21 PM Joseph Salowey  wrote:
> > 1.  Do you support the working group taking on future work on a pinning 
> > mechanism (based on the modifications or another approach)?
> 
> I don't think that pinning is a good idea.  We've experience that
> suggests that it's more of a footgun than a useful mechanism.  That
> isn't to say that there isn't a domain where it makes sense.

Did you oppose MTA-STS?  The proposed "pinning" is very much like
a simpler form of MTA-STS, and nothing unlike HPKP.

Perhaps it would be much less confusing if we stopped calling it
"pinning" (which seems to be a traumatic memory trigger for the
HTTP community).  We can call this "strict TLS DANE chain" or some
such, which is a much better analogy in any case.

-- 
Viktor.

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Eric Rescorla]

On Wed, Jul 4, 2018 at 7:33 PM, Viktor Dukhovni 
wrote:

> On Wed, Jul 04, 2018 at 06:34:44PM -0700, Eric Rescorla wrote:
>
> > > 1.  Do you support the working group taking on future work on a pinning
> > > mechanism (based on the modifications or another approach)?
> >
> > Unsure. I'd like to see some real evidence that it will be widely
> consumed.
> > Do we have a count of major implementors who say they will do so?
>
> Well, what is a "major implementation"?


Well, we could start with "what implementations are going to do this"?


> No. I'm undecided on whether we should have an extension point here, but
> > I'm strongly against having it just be opaque reserved bytes. Everywhere
> > else we have decided to put extension points, we've had them as
> Extensions,
> > not just "here are some bytes".  Aside from this being general TLS
> > practice, it is good futureproofing because one can grease Extensions,
> > whereas you cannot grease opaque bytes.
>
> It is far from clear why "grease" is applicable here, or what "grease
> barriers" either proposed form of the reserved field presents.
>
> * With the 16-bit field, servers set it to zero until non-zero
>   values are specified.
>

> * With the <0..255> byte value, servers send an empty value
>   until non-empty values are specified.
>

* In either case clients ignore either non-zero or non-empty
>   values, until they implement the specification, and must not
>   employ pinning until such time.
>

Yes, and this is where grease comes in. Specifically, if implementations
are required to send empty values (or zero) until something is specified,
then implementations which *require* those values and choke otherwise go
undetected. By contrast, if we have a structured Extension code point with
requirements to ignore unknown extensions, then implementations can send
grease extension values and verify that the peer properly ignores them. In
any case, as Martin Thomson says, we have a perfectly good extension
mechanism which can be used to add pinning later without creating any
placeholder here.

I thought the authors wanted this done quickly, but lately they
> seem to be in no rush to get the document finished.


Well, I'm not an author, so I'm the wrong person to be addressing this to.


If we're no
> longer in a hurry to get this out the door before all the issues
> are sorted out, we can specify the downgrade protection now, in
> which case there's no need for reserved fields, we can define the
> pinning approach now.
>

That would first require there being consensus to do pinning.

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Melinda Shore]

On 7/4/18 6:33 PM, Viktor Dukhovni wrote:
> I thought the authors wanted this done quickly, but lately they
> seem to be in no rush to get the document finished. 

I'm still trying to figure out a way forward that's useful
for the people who intend to use this extension and that doesn't
add cruft or ambiguity.  Unfortunately there doesn't appear to
be one, so compromise is necessary.

I also think there's been already been a pretty serious process abuse
here and tend to think that the new implication that we can go forward
in a timely way if everybody just agrees with you is additionally
problematic.  But as I said earlier, I'll go along with the working
group consensus and will not block a decision I don't happen to like.
That's the implicit contract we sign with the IETF when we decide to
bring work here.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
 34C0 DFB8 9172 9A76 DB8F

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Viktor Dukhovni]

On Wed, Jul 04, 2018 at 06:51:46PM -0800, Melinda Shore wrote:

> On 7/4/18 6:33 PM, Viktor Dukhovni wrote:
> > I thought the authors wanted this done quickly, but lately they
> > seem to be in no rush to get the document finished. 
> 
> I'm still trying to figure out a way forward that's useful
> for the people who intend to use this extension and that doesn't
> add cruft or ambiguity.  Unfortunately there doesn't appear to
> be one, so compromise is necessary.

Since the updated security considerations and new denial of existence
text are not looking controversial, it would be helpful to all
parties to get a new revision out with those merged so they can be
polished and put behind us.  That leaves just the reserved field
unresolved.

-- 
Viktor.

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Viktor Dukhovni]

On Wed, Jul 04, 2018 at 07:46:13PM -0700, Eric Rescorla wrote:

> > > Do we have a count of major implementors who say they will do so?
> >
> > Well, what is a "major implementation"?
> 
> Well, we could start with "what implementations are going to do this"?

Since Postfix supports not just MTA-to-MTA SMTP, but also SUBMIT,
and I am a maintainer of both the TLS features in Postfix, and the
X.509 code in OpenSSL, I expect to add support for DANE chain in
OpenSSL and Postfix in 2019.  Next on the list would be Dovecot and
mutt, but it'd be nice if that was done by one of the primary
maintainers of those packages.

> Yes, and this is where grease comes in. Specifically, if implementations
> are required to send empty values (or zero) until something is specified,
> then implementations which *require* those values and choke otherwise go
> undetected.

Any broken clients will get fixed.  The client that motivated this
draft is purported to require the extension, and the others will
take some time to appear, highly likely not until the follow-on
spec is written.  The odds of real problems here are negligible.

> By contrast, if we have a structured Extension code point with
> requirements to ignore unknown extensions, then implementations can send
> grease extension values and verify that the peer properly ignores them.

There's no need for nested extensions, they serve no purpose.  If DANE
chain STS is in a separate extension, it may as well be top-level.

> any case, as Martin Thomson says, we have a perfectly good extension
> mechanism which can be used to add pinning later without creating any
> placeholder here.

At much too much complexity, unless we fork-lift this extension
plus the additional payload, and largely obsolete this draft.  Using
one extension to pin itself and another is much too cumbersome.

> > If we're no
> > longer in a hurry to get this out the door before all the issues
> > are sorted out, we can specify the downgrade protection now, in
> > which case there's no need for reserved fields, we can define the
> > pinning approach now.
> 
> That would first require there being consensus to do pinning.

That is, to address the security gap highlighted in the upcoming
more complete security considerations.  s/pinning/DANE chain STS/

-- 
Viktor.

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Eric Rescorla]

On Wed, Jul 4, 2018 at 8:16 PM, Viktor Dukhovni 
wrote:

> On Wed, Jul 04, 2018 at 07:46:13PM -0700, Eric Rescorla wrote:
>
> > > > Do we have a count of major implementors who say they will do so?
> > >
> > > Well, what is a "major implementation"?
> >
> > Well, we could start with "what implementations are going to do this"?
>
> Since Postfix supports not just MTA-to-MTA SMTP, but also SUBMIT,
> and I am a maintainer of both the TLS features in Postfix, and the
> X.509 code in OpenSSL, I expect to add support for DANE chain in
> OpenSSL and Postfix in 2019.  Next on the list would be Dovecot and
> mutt, but it'd be nice if that was done by one of the primary
> maintainers of those packages.
>

It would be nice to hear from those maintainers, as well as from some of
the bigger email senders (e.g., GMail, Yahoo Mail, etc.)


> Yes, and this is where grease comes in. Specifically, if implementations
> > are required to send empty values (or zero) until something is specified,
> > then implementations which *require* those values and choke otherwise go
> > undetected.
>
> Any broken clients will get fixed.  The client that motivated this
> draft is purported to require the extension, and the others will
> take some time to appear, highly likely not until the follow-on
> spec is written.  The odds of real problems here are negligible.
>

It has not been my experience or, I think, that of the WG, that this is the
case. Rather, once there is a significant fielded population of intolerant
endpoints, generating the offending PDU causes too much breakage and
instead you have to send something which doesn't break those endpoints. cf.
the padding extension, supported_versions, and the CCS hack.


> any case, as Martin Thomson says, we have a perfectly good extension
> > mechanism which can be used to add pinning later without creating any
> > placeholder here.
>
> At much too much complexity, unless we fork-lift this extension
> plus the additional payload, and largely obsolete this draft.  Using
> one extension to pin itself and another is much too cumbersome.
>

Yes, I appreciate that this is your opinion.

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Paul Wouters]

On Wed, 4 Jul 2018, Eric Rescorla wrote:


In any case, as Martin Thomson says, we have a perfectly good
extension mechanism which can be used to add pinning later without creating any 
placeholder here.


The IETF should not publish security protocols that are trivially downgraded.

The work _should_ really be completed within this document to address
all downgrade attacks. As a _compromise_ there have been suggestions
done to let this document be published while commiting to a method for
downgrade protection. That was not an invitation to punt it to infinity
or an invitation to have a bis replace this entire document just to be
ignored because some people only care about the DOH case. Besides, we
would end up with identical specs apart from two bytes and the same
discussion about these two bytes would happen about whether the new
document Obsoletes: this one. It won't resolve the issue at all and
meanwhile some people have implemented and deployed a protocol that can
be trivially downgraded, or bothered to just not implement because it
offers no real security benefit.

If you don't like TLS extension pinning, come up with another mechanism
that resolves the downgrade attack. But note that none of the comments
against using two bytes for hour scale extension pinning withstood
scrutiny and half of them were appeals to authority or based on people's
gut feelings.

So far, I've only heard incorrect comparisons with other pinning mechanism
problems that ignore the fact that the source of this extension material
is in DNSSEC and that the extension data is a "live snapshot" of active
DNSSEC data and thus never stale/old/bad/brokeb.


That would first require there being consensus to do pinning.


Again, why do you think it would be even valid to have consensus to
deploy a trivially downgradable security mechanism? I would certainly
expect the IESG to send this back to the drawing board, even if they
missed it on their first evaluation round.

Paul

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Viktor Dukhovni]

On Wed, Jul 04, 2018 at 08:42:38PM -0700, Eric Rescorla wrote:

> It would be nice to hear from those maintainers, as well as from some of
> the bigger email senders (e.g., GMail, Yahoo Mail, etc.)

The question is premature, some implementations are not candidate
early adopters.  Once library support is there, and there are
some early adopters deployed, then the others follow.

Postfix implemented DANE in 2014, a bunch additional MTAs added
support in 2017 and 2018, and I expect more in 2019.

> > Any broken clients will get fixed.  The client that motivated this
> > draft is purported to require the extension, and the others will
> > take some time to appear, highly likely not until the follow-on
> > spec is written.  The odds of real problems here are negligible.
> 
> It has not been my experience or, I think, that of the WG, that this is the
> case.

Yes, that's true with major TLS revisions.  This extension, however,
will not see such rapid uptake that sloppy early versions will need
to be revised.  You're on the one hand questioning whether any
adoption will take place at all, and on the other concerned that
early adopters will be intolerant of non-sentinel values of the
proposed reserved field.  Your first concern is closer to the mark.

While I'd like to have the second problem, the reality is that for
the first couple of years the number of implementations will be
rather small, and the specification of the reserved field can and
should predate the bulk of the follow-up implementations.

> Rather, once there is a significant fielded population of intolerant
> endpoints, generating the offending PDU causes too much breakage and
> instead you have to send something which doesn't break those endpoints. cf.
> the padding extension, supported_versions, and the CCS hack.

Sure, but "significan fielded population" is not a problem we'll
be having here for some time.  This is a space where uptake will
be slow, and the early adopters will be well aware of the requirements.
By the time the late adopters arrive, we'll have the downgrade
protection fully specified.

-- 
Viktor.

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

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Paul Wouters]

On Wed, 4 Jul 2018, Eric Rescorla wrote:


  > > > Do we have a count of major implementors who say they will do so?
  > >
  > > Well, what is a "major implementation"?
  >
  > Well, we could start with "what implementations are going to do this"?


[postfix and openssl apparently not big enough ]


It would be nice to hear from those maintainers, as well as from some of the 
bigger email senders (e.g., GMail, Yahoo Mail,
etc.)


This is not a valid direction for this technical discussion, and goes
pretty directly against the Tao of the IETF. But if you want to go
that way, here is my proposed question to those providers:

Do you object to your company's product needing to send two
additional zero bytes in a TLS handshake if/when you support
DANE stappling in TLS in the case that you do NOT want to be
protected from downgrade attacks so that other entities that DO
want to support downgrade protection can do so without creating
yet another a mostly duplicate internet standard that comes with
its own delay in deployment?

I am fine with people believing they do not need downgrade protection,
although in my experience most downgrade possibilities end up getting
abused at some point for malicious purposes. But it would be great if
those people could reciprocate that freedom of choice to those that do
want downgrade protection so they can make actual security decisions
based on this standard.

Thank you,

Paul

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

Re: [TLS] Broken browser behaviour with SCADA TLS

[Ilari Liusvaara]

On Thu, Jul 05, 2018 at 02:02:04AM +, Peter Gutmann wrote:
> Ilari Liusvaara  writes:
> 
> >Chrome initially did that. It caused quite a lot of bad feedback from owners
> >of various bad embedded stuff. The thread on relevant forums was quite
> >something. Hundreds of messages blaming Google for breaking stuff.
> 
> If there were "hundreds of messages" doesn't that indicate that it's Chrome
> that's the problem, and not everyone else?

Basically with DHE in TLS 1.2, you have very few choices:

1) Advertise DHE, accept weak groups. Vulernable to LOGJAM.
2) Advertise DHE, deny weak groups. Unacceptable failure rates.
3) Do not advertise DHE. Loses FPS with some servers.
4) Try DHE at first and fallback to RSA on too small group.
   Complex.


-Ilari

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