Re: [TLS] ML-KEM key agreement for TLS 1.3

[David A. Cooper]

I do not believe that "decode_error" would be the correct alert. As the 
text currently says:


   *Failures* Some post-quantum key exchange algorithms, including
   ML-KEM, have non-zero probability of failure, meaning two honest
   parties may derive different shared secrets. This would cause a
   handshake failure. ML-KEM has a cryptographically small failure
   rate; implementers should be aware of the potential of handshake
   failure. Clients can retry if a failure is encountered.

At least in the case of ML-KEM, decapsulation failures are implicit. As 
noted in the text above, the parties would derive different shared 
secrets (but they wouldn't know it). So, the client would not know that 
decapsulation failed, it would just be unable to decrypt the encrypted 
extensions, certificate, etc. The client would have no way of knowing 
whether this happened because of an ML-KEM decapsulation failure 
(extremely unlikely) or because some data was changed in transit (much 
more likely).


Given how small the ML-KEM decapsulation failure rate is (2^-139 or 
less), I wouldn't be surprised if random bit flips in transit that 
aren't caught by a CRC or other check are more likely than ML-KEM 
decapsulation failures. Since the two are indistinguishable to the 
client, the client would have to handle them in the same way. So, I 
would suggest either omitting this paragraph or just note that a 
decapsulation failure would be indistinguishable from a scenario in 
which some data was changed in transit, and so would be handled in the 
same way.


On 3/13/24 7:08 PM, Deirdre Connolly wrote:


4. In the Discussion section (on github), does the portion on
failures need to contain more information about how a failure
should be handled in TLS? Should a decrypt_error alert be sent?


Oh very good point, DH doesn't usually fail like this; either because 
of fundamental (incredibly unlikely) decapsulation failure rates, or 
just a bug, this is good to handle, and we should probably update 
-hybrid-design to match. I've tracked this in this GitHub issue 
 
for now. For my own sake, here's the `decode_error` defintion from RFC 
8446:


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.  This alert should

      never be observed in communication between proper
implementations,

      except when messages were corrupted in the network.

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

Re: [TLS] Another ClientHello length intolerance bug?

[David A. Cooper]

  
  
It would be unlikely to hit this bug in
  practice. I just tried a test with Chromium 65. In the default
  configuration, with a 9-byte server name, the TLSCiphertext.length
  was 192 bytes. So, in order to hit the bug it would seem that the
  server's DNS name would have to be exactly 83 bytes. When I
  changed the configuration to enable TLS 1.3 the ClientHello
  included a rather long padding extension to make
  TLSCiphertext.length exactly 512 bytes.
  
  I just happened to hit this since I was sending a ClientHello
  message with several public keys in the key_share extension
  (including ffdhe keys).
  
  David
  
  On 09/12/2018 12:38 PM, David Benjamin wrote:


  
  Wow! That's a bizarre one. I don't think we've run
into this one before, but, from your description, any given
implementation would only have a 1/256 chance of hitting it on
every ClientHello change.


10 is a newline, so perhaps some implementation is doing a
  terrible job detecting TLS vs. some plaintext protocol. No
  idea about 14. (This kind of broken and unsound
  protocol-guessing behavior appears to be sadly common. Some
  buggy middlebox started misidentifying our ClientHellos as SIP
  when we removed the pre-standard ChaCha20 cipher suites!)
  
  
  Do you have an example server? It would be good to get
the problematic implementation fixed.
  
  


  
David
  


  

  
On Wed, Sep 12, 2018 at 9:24 AM David A.
  Cooper <david.coo...@nist.gov>
  wrote:


   According to
RFC 7685 there was at least one TLS implementation
that would hang the connection if it received a
ClientHello record with a TLSCiphertext.length
between 256 and 511 bytes.

During some recent testing I believe that I have
come across a similar length intolerance bug. A
number of servers seem to hang or close the
connection if sent a ClientHello record with a
TLSCiphertext.length of 266, 522, 778, ... (i.e., if
TLSCiphertext.length mod 256 = 10). I have
also encountered one server that will also hang the
connection if sent a ClientHello record with a
TLSCiphertext.length of 270, 526, 782 ... (i.e., if
TLSCiphertext.length mod 256 = 14).

A test for this was just added to the development
branch of testssl.sh (https://github.com/drwetter/testssl.sh)
-- run testssl.sh with the "--grease" option.

As the server banner being returned by the servers
that seem to have this problem are not all the same
it is my guess that it is actually some middlebox
that the is the source of the problem.

Has anyone else encountered this problem? We are
trying to validate that this is a real bug (https://github.com/drwetter/testssl.sh/pull/1113).

Thanks,

David

  
  ___
  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

[TLS] Another ClientHello length intolerance bug?

[David A. Cooper]

  
  
According to RFC 7685 there was at least one TLS implementation that
would hang the connection if it received a ClientHello record with a
TLSCiphertext.length between 256 and 511 bytes.

During some recent testing I believe that I have come across a
similar length intolerance bug. A number of servers seem to hang or
close the connection if sent a ClientHello record with a
TLSCiphertext.length of 266, 522, 778, ... (i.e., if
TLSCiphertext.length mod 256 = 10). I have also encountered
one server that will also hang the connection if sent a ClientHello
record with a TLSCiphertext.length of 270, 526, 782 ... (i.e., if
TLSCiphertext.length mod 256 = 14).

A test for this was just added to the development branch of
testssl.sh (https://github.com/drwetter/testssl.sh) -- run
testssl.sh with the "--grease" option.

As the server banner being returned by the servers that seem to have
this problem are not all the same it is my guess that it is actually
some middlebox that the is the source of the problem.

Has anyone else encountered this problem? We are trying to validate
that this is a real bug
(https://github.com/drwetter/testssl.sh/pull/1113).

Thanks,

David

  


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

[TLS] draft-ietf-tls-grease and RFC 7919

[David A. Cooper]

I would like to suggest that one additional value be added to the list 
of GREASE values for named groups.


Section 2 of RFC 7919 says:

   Codepoints in the "Supported Groups Registry" with a high byte of
   0x01 (that is, between 256 and 511, inclusive) are set aside for
   FFDHE groups.

Section 4 of RFC 7919 says:

   If a compatible TLS server receives a Supported Groups extension from
   a client that includes any FFDHE group (i.e., any codepoint between
   256 and 511, inclusive, even if unknown to the server), and if none
   of the client-proposed FFDHE groups are known and acceptable to the
   server, then the server MUST NOT select an FFDHE cipher suite.


So, it would be helpful in testing this requirement of RFC 7919 if there 
were one GREASE value for named groups between 261 and 507 (according to 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8, 
these are the values in the specified range that are currently unassigned).


Thank you,

David

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

Re: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity

[David A. Cooper]

I believe you are misinterpreting the text, but agree that it could be 
made more clear.


Suppose that the ClientHello includes a supported_versions extensions 
that contains two values, TLS 1.4 and TLS 1.0, and the server supports 
TLS 1.3 and below. My interpretation of the current draft is that the 
server MUST use the supported_versions extension to determine the 
client's preference, but then once deciding to use TLS 1.0 for the 
connection sends a normal TLS 1.0 ServerHello, with version field set to 
0x0300 and no supported_versions extension. Note that Section 4.2.1 says 
that


 A server which negotiates TLS 1.3 MUST respond by sending a
 "supported_versions" extension containing the selected version
 value (0x0304).

It says nothing about a server that negotiates an earlier version.

If my understanding is correct, then I believe the text in Section 4.1.3 
could be made more clear. Draft -21 said that the version field of 
ServerHello "contains the version of TLS negotiated for this 
connection." (this is similar to what RFC 5246 said). The current draft 
says:


  In TLS 1.3, the TLS server indicates its version using the
  "supported_versions" extension (Section 4.2.1), and the
  legacy_version field MUST be set to 0x0303, which is the
  version number for TLS 1.2.

To be consistent with RFC 5246 and earlier, it seems like the text 
should say something like:


  For a TLS 1.3 ServerHello the TLS server indicates its version
  using the "supported_versions" extension (Section 4.2.1), and
  the legacy_version field MUST be set to 0x0303, which is the
  version number for TLS 1.2. For a TLS 1.2 and earlier ServerHello
  the legacy_version field contains the version of TLS negotiated
  for this connection.

On Thu, Mar 1, 2018 at 5:24 AM, Nikos Mavrogiannopoulos 
 wrote:



The TLS draft after version -21 requires TLS1.3 servers to negotiate
pre-TLS1.3 versions with a new, mechanism. The document states:

   "If this extension is present, servers MUST ignore the
   ClientHello.legacy_version value and MUST use only the
   "supported_versions" extension to determine client preferences."

...

   "Note that this mechanism makes it possible to negotiate a
   version prior to TLS 1.2 if one side supports a sparse range."


At this point, a server receiving a supported_versions extension which
contains the single value 'TLS 1.0' has to follow the draft's
recommendations and do:

  1. It MUST set the ServerHello.legacy_version field to 0x0303
 (TLS 1.2).
  2. On the serverHello extensions include a supported_versions
 extension and advertise TLS1.0

That modifies the way TLS 1.1  or TLS 1.0 are negotiated, possibly
introducing new issues with middle-boxes which see TLS1.2 in the
ServerHello but TLS1.0 anywhere else. That is also a quite impossible
code path (why would an implementation negotiate TLS1.0 using a TLS1.3
mechanism?). It is however anticipated to be used for that purpose as
this draft mentions:

   "Servers should be prepared to receive ClientHellos that include
    this extension but do not include 0x0304 in the list of versions."

Irrespective to any middle-box issues, I believe impossible code paths
allowed by the protocol are more likely to cause problems than solve
any, because they are often not tested, and provide attackers with
additional tools to manipulate implementations.

My recommendation to address that would to either ignore that extension
if pre-TLS1.2 is negotiated, or revert to -21 draft behavior for pre-
TLS1.3 protocol negotiation. That is, the server MUST not send the
supported_versions extension if a pre-TLS1.3 protocol is to be
negotiated. The first case ensures that there is a single way to
negotiate TLS1.x, where x<3, and the second that the clientHello
extension is only used informatively.

regards,
Nikos


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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[David A. Cooper]

  
  
No, they would not prevent those other
  mechanisms. Where is your evidence that they would?
  
  If the "attacker" controls the software that the client is using,
  then it would set up the software to not check public-key pinning
  or CT, if necessary. As Richard noted, this may not even require
  developing custom software. It may be as simple as distributing a
  standard browser with its own CA added as a "user-installed" root
  certificate.
  
  In the case that the "attacker" has the cooperation of the server,
  and the client is using unmodified software, then the data sent
  between the client and server (including the server's certificate)
  would be no different than if the server wasn't allowing the
  "attacker" to have access to the data. There would be no
  information available to the client at all that would distinguish
  between scenarios in which the server either is or isn't allowing
  another party to have access to the data being transmitted over
  the TLS session.
  
  If public-key pinning and CT would prevent other mechanisms from
  working, please explain in detail how they would do so. Or better
  yet, let's end this line of discussion and work on finding
  mutually agreeable solutions to the underlying problem.
  
  On 10/25/2017 12:12 PM, Richard Barnes wrote:


  
  On Wed, Oct 25, 2017 at 12:06 PM, Salz, Rich 
wrote:

  
> since those other means would be easier
and more effective. You
    have done nothing to suggest otherwise.

  Public-key pinning and CT seem like they would
  prevent those other mechanisms.  No?



Remember that non-default, user-installed root
  certificates are exempted from those mechanisms in all
  current browsers.


--Richard



 

  

  ___
  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] Publication of draft-rhrd-tls-tls13-visibility-00

[David A. Cooper]

I've already responded to this! Why are you wasting everyone's time by 
asking the same questions over and over, even though I've already 
clearly answered them?


An airplane/wifi provider might say "download our free browser," but it 
won't rely on draft-rhrd-tls-tls13-visibility to snoop on its customers. 
If the airplane/wifi provider controls the software on its customers' 
computers, it doesn't need the cooperation of the servers that the 
customers are connecting to in order to snoop, so it wouldn't go through 
the effort of trying to get that cooperation. And, if the airplane/wifi 
provider has the cooperation of the servers that the customers are 
connecting to it doesn't need to convince its customers to download any 
software or in any other way get the customers to cooperate in allowing 
the snooping, so it won't bother.. If you believe otherwise, then you 
are the one who is being very naïve.


I can't guarantee that enterprise visibility will stop at the enterprise 
firewall. My argument is simply that use of the protocol in this draft 
will stop at the enterprise firewall since outside the firewall, when 
communicating with clients outside of the enterprise's control, the 
enterprises that want to enable "visibility" into such traffic will use 
other means that don't require the the cooperation or knowledge of the 
clients, since those other means would be easier and more effective. You 
have done nothing to suggest otherwise.


On 10/25/2017 10:56 AM, Salz, Rich wrote:

This question is based on your that belief that this protocol will "escape" 
onto the public Internet

Yes.  Are you saying that you don’t believe that the enterprise visibility will 
stop at their firewall?  That they will allow ‘stock’ TLS 1.3 to work 
connecting to their sites?  That the airplane/wifi provider won’t say ‘download 
our free browser’?

I think you’re being very naïve to think otherwise.




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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[David A. Cooper]

This question is based on your that belief that this protocol will 
"escape" onto the public Internet, that browsers and other clients used 
by individuals will feel forced to implement it, and that clients will 
then be forced to enable the extension in order to get through 
middleboxes that would filter traffic based on whether or not the 
extension is present in the ClientHello. I've already explained why I 
believe that scenario will never happen, and so no I do not agree that 
it is a "fundamental change."


The idea of a client extension was added based on feedback at the Prague 
meeting in order to help prevent the protocol from being used over the 
public Internet, by preventing the protocol from being used without the 
client's knowledge. Obviously you believe that the method being proposed 
to address one concern introduces another concern. I do not share those 
concerns for the reasons that I've already stated.


I don't plan to comment on this issue any further, and doing so would 
just be repeating myself, thus just adding to the noise.


On 10/25/2017 10:28 AM, Salz, Rich wrote:

➢ Similarly, the best that TLS can offer in terms of privacy is that the
 contents of the communication between the two endpoints is not seen by
 anyone else *unless* at least one of the two endpoints (client or
 server) chooses to provide the contents of the communication to some
 other entity. draft-rhrd-tls-tls13-visibility doesn't change that.
 
Yes it does.  It signals on the wire to any observer that the client and server agree to this.  TLS never attempted to control what the client or server could do. But it never put any such signal on the wire. This is an important and fundamental change, and it allows traffic to be categorized and handled differently.


Do you agree with that?



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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[David A. Cooper]

Everything I have stated is my personal opinion.

Note that I never suggested that I like or am espousing a certain 
approach, I was simply stating a fact. In many cases today, a TLS 
connect that appears to a client to be terminating a one place (Company 
X) is actually terminating somewhere else (Hosting Provider Y) without 
any clear indication to the client that the connection is terminating at 
Hosting Provider Y. Nobody has suggested that this is unacceptable or 
that TLS is broken if it can't prevent that.


TLS is not an end-to-end protocol, it is a point-to-point protocol, and 
as noted in hosting company example, which you claim to find so 
troubling, it isn't always clear to either party what's at the other end 
of the connection. It might be the entity the client thinks its 
connecting to (Company X), it might be a hosting provider acting on 
behalf of Company X, or it might be something else. The best the client 
can hope for with things like TLS, PKIX, TRANS, etc., is that the server 
end of the connection is either Company X or some entity authorized by 
Company X to act as Company X for the purpose of being the connection 
endpoint (and, yes, Company X may have been coerced into authorizing 
some other entity to covertly act as the server endpoint). I am not 
saying that I like this or am "espousing" it, I am simply pointing out a 
fact.


Similarly, the best that TLS can offer in terms of privacy is that the 
contents of the communication between the two endpoints is not seen by 
anyone else *unless* at least one of the two endpoints (client or 
server) chooses to provide the contents of the communication to some 
other entity. draft-rhrd-tls-tls13-visibility doesn't change that.


It is also a fact that once a client provides data to a server, there 
are no technical mechanisms that would allow the client to limit what 
the server does with that data. As has been show over and over again, 
including by you, it is very frequently the case that the server that 
initially receives the data passes it on to others. The others may be 
back-end database servers or anti-virus scanners, but the client has no 
control over what happens to the data once the server receives it.


I have not tried to argue that draft-rhrd-tls-tls13-visibility is the 
best solution for addressing the need for visibility within the data 
center. Perhaps it is, perhaps it isn't. But, I'm tired of the abusive 
and false suggestions that draft-rhrd-tls-tls13-visibility is a 
"wiretapping" draft or that it is defining a "please-screw-me 
extension." These suggestions have been repeated over and over again, 
even though they have already been countered effectively - "repeating 
points already countered is just disruptive noise."


On 10/24/2017 10:13 PM, Stephen Farrell wrote:

David,

I'll go back over your mails tomorrow but was struck by this...

On 24/10/17 23:39, David A. Cooper wrote:

I haven't even gotten into the question of what does it mean for a connection to
be MiTM'd. If Company X decides to have its web site operated by Hosting
Provider Y is the connection between the client and Company X being MiTM'd? The
client might think it has a secure end-to-end connection with Company X, but in
reality its data is being intercepted and read by Hosting Provider Y, without
the client's permission (and most likely without the client's knowledge). How
does TLS, currently, prevent this? Why isn't anyone demanding that TLS cannot be
standardized until it can be proven that such a scenario is impossible?

That strikes me as an incredibly nihilist approach you
(or NIST?) appear to be espousing, which is surprising.

As a question back to you: would it be ok if NIST were
to reinstate Dual-EC? If not why not? After all, (based
on the above), all that'd happen is someone could do
stuff that everyone knows (since 2008) can happen. (And
no, with the current draft, the client does NOT know who
the snooper is - it could be the NSA or the FSB and the
client can't tell - and all that was already discussed
on the list.)

I suspect you'll say that it's better that NIST do not
add Dual-EC back, (and I agree) because we're better off
with honest crypto. And the same is true of TLS - it's
a 2 party protocol and adding additional parties breaks
all the trust models based on TLS. So it'd be equally
good if NIST didn't espouse breaking TLS, at least IMO.

If you can show me where you (or NIST or anyone) analysed
all of the uses of TLS to check that there are no bad side
effects, I'll be interested in reading that analysis. In
the meantime, your personal evaluation of your risk is not
something that I find convincing, sorry.

S.



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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[David A. Cooper]

  
  
On 10/24/2017 05:18 PM, Salz, Rich
  wrote:


  
  
  
  
  
  
 

  And, I don't
buy the idea that if this extension is standardized that it
will be implemented in commonly-used browsers.

 
And that is a risk you are willing for the
  entire public Internet to take?
  


I'm not taking any risk.  The ability for a server to allow a third
party to have access to data it is exchanging with a client already
exists, and that ability isn't going away whether this proposal (or
something similar) is standardized or not. As I've already pointed
out, for the scenarios people are concerned about, the "attacks"
being described would be much more easily carried out by some means
other than draft-rhrd-tls-tls13-visibility.

So, no I am not worried about the "risk" of creating a complicated
way for servers and middleboxes to collude to do something that they
can already do now in a simpler way.


  
And what about the fact that it provides a
  cleartext signal as to whether or not a client is willing to
  let itself be MiTM’d, does that bother you?
  


No. As I noted before, servers can already allow middleboxes to MiTM
connections with clients with asking the client's permission. Public
facing servers that want to allow this (even if as a result of
coercion) won't use this extension. They'll just enable it without
informing the clients.

There are also other ways a server could allow a middlebox to MiTM
the connections that it has with clients that don't require the
client's cooperation (or knowledge) and that wouldn't require any
changes on the client side; ways that would be easier than trying to
use draft-rhrd-tls-tls13-visibility.

If the only way (or the easiest way) these connections could be
MiTM'd required getting clients' permission, then this might be a
concern, I don't see servers that want to (or are coerced into)
allowing connections to be MiTM'd asking clients whether they are
willing. Given this, we aren't going to see browsers that are
configurable to signal that the client is willing to "allow" the
connection to be MiTM'd.

I haven't even gotten into the question of what does it mean for a
connection to be MiTM'd. If Company X decides to have its web site
operated by Hosting Provider Y is the connection between the client
and Company X being MiTM'd? The client might think it has a secure
end-to-end connection with Company X, but in reality its data is
being intercepted and read by Hosting Provider Y, without the
client's permission (and most likely without the client's
knowledge). How does TLS, currently, prevent this? Why isn't anyone
demanding that TLS cannot be standardized until it can be proven
that such a scenario is impossible?



  


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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[David A. Cooper]

  
  
As difficult as what you describe below
  would be, using draft-rhrd-tls-tls13-visibility to snoop would be
  much more complicated. They would need to need to get their
  "special" browsers onto all of the students' devices, but then,
  unlike in the scenario below, that would only be the beginning of
  what they need to do. They would need to active cooperation of
  every TLS-protected server that the students could connect to and
  they would need an infrastructure for obtaining and managing all
  of the keys that they would be getting from all of these servers.
  [In practice, of course, there wouldn't be that many keys since
  practically no servers would cooperate in this scheme.]
  
  So, yes, setting up a scheme to snoop on all outgoing
  TLS-protected traffic would not be easy. However,
  draft-rhrd-tls-tls13-visibility would not make it easier than it
  currently is, as implementing something based on
  draft-rhrd-tls-tls13-visibility would be far more difficult than
  using currently available methods.
  
  And, I don't buy the idea that if this extension is standardized
  that it will be implemented in commonly-used browsers. We don't
  have to "keep all the plates spinning" in order to prevent this
  extension from "escaping" on to the public Internet. This isn't
  something that could "accidentally" be implemented in browsers if
  browser vendors don't take extreme precautions to prevent it from
  happening. Browser vendors would have to pro-actively decide to
  implement this, and I don't see that happening. The idea that
  someone would set up a service that would only work if browsers
  implemented this extension, and then browsers would be "forced" to
  implement the extension so that this service would work isn't
  realistic.
  
  A server that wanted to allow third party interception of traffic
  between itself and its clients wouldn't require this extension and
  then wait for browsers to implement the extension. It would just
  use TLSv1.2 with RSA key exchange (or something like
  draft-green-tls-static-dh-in-tls13), and then set up the
  interception capability without the client's knowledge.
  
  On 10/24/2017 04:38 PM, Yoav Nir wrote:

  
On 24 Oct 2017, at 22:54, David A. Cooper  wrote:

Why would these schools settle for a half measure that only allows them to snoop on traffic between their students and servers provide the keys to their Internet traffic to the schools? If a school wants to snoop on its students' traffic, it would do so in a much easier way than using draft-rhrd-tls-tls13-visibility, in the same way that some enterprises today use middleboxes to inspect all outgoing traffic.

  
  
Yeah. I used to write such middleboxes. They’re a nightmare to deploy in all but the most orderly of enterprises. You need to have all clients trust the middlebox CA. Fine, so the Windows computers get that installed through SMS or GPO or whatever the central configuration feature is called these days. The people with Macs have to figure it out for themselves, and the same goes for people with phones. Oh, and also for people who use Firefox, because that browser comes with its own trust store. The people on this list can probably figure it out with a little web search. A school with a thousand students all bringing their own devices? Good luck.


  
This browser that students would be required to use would be one that has a CA controlled by the middlebox installed as a trust anchor. Whenever one of the students' clients tries to connect to an external secure site, the middlebox-controlled CA issues a certificate for that site so that the connection can be terminated at the middlebox. The middlebox then establishes a secure connection with the end server, thus setting up the middlebox as a MiTM.

  
  
It’s one thing to say that SchoolBrowser (conveniently located in the app stores of all phone and computer OS-es) works in this school (and all the others).  It’s a totally different thing to fill the app stores with “GrizzlyBrowser for Logan High School students” and “MustangBrowser for Mountain Crest High School students"


  
There are already middleboxes on the market today that do this. They work for all outgoing connections and don't require any cooperation whatsoever from the outside servers that the clients are trying to connect to, and only expert users would notice the presence of the MiTM.

  
  
Unless they had to configure their browser themselves.  The support costs of these is tremendous.




  


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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[David A. Cooper]

  
  
On 10/24/2017 04:24 PM, Ted Lemon
  wrote:


  
  On Oct 24, 2017, at 4:21 PM, David A. Cooper <david.coo...@nist.gov> wrote:
  

  I'm not suggesting that cash strapped schools
  would use one of these devices. I'm simply saying that
  such a solution would be simpler and far more effective
  than trying to use draft-rhrd-tls-tls13-visibility to
  snoop on outgoing traffic.
  

  
  
  Again, if that were true, then it would also be true
that these devices would nicely solve the problem that
draft-rhrd-tls-tls13-visibility solves.


Not at all. Visibility in the data center is a totally different
problem than inspecting outgoing traffic. In the data center case
the same organization controls the clients, servers, and the
authorized listeners. That is very different from a scenario in
which the organization that wants to listen in is different from the
organizations that control the servers, and in which the
organizations that control the servers are unlikely to want to grant
this intermediary the ability to listen in on the traffic between it
and its clients.

Also, in the data center case, there is no middlebox. Others, who
know much more than I do about operational constraints in data
center environments, have already argued that setting up a bunch of
middleboxes would not be a viable solution.

  


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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[David A. Cooper]

  
  
I'm not suggesting that cash strapped
  schools would use one of these devices. I'm simply saying that
  such a solution would be simpler and far more effective than
  trying to use draft-rhrd-tls-tls13-visibility to snoop on outgoing
  traffic.
  
  Those who are suggesting draft-rhrd-tls-tls13-visibility could be
  used to snoop on outgoing traffic are imagining a scenario in
  which the school (or other snooper) would make arrangements with
  each TLS-protected server that they would allow their clients to
  connect to receive copies of the keys that would be needed to
  decrypt the traffic. How effective would that be? How expensive
  would that be?
  
  Besides, the scenario I described previously is just one
  possibility (although perhaps the easiest to implement). The
  software that the middlebox requires clients to use could just
  send the traffic in plaintext to the middlebox while falsely
  indicating to the client that the connection is secure. Plainly,
  if the attacker developed the software that the client is running,
  then there is no protection from the attacker.
  
  On 10/24/2017 04:01 PM, Ted Lemon wrote:


  
  On Oct 24, 2017, at 3:59 PM, Ted Lemon <mel...@fugue.com>
  wrote:
  

  On Oct 24, 2017, at 3:54 PM,
          David A. Cooper <david.coo...@nist.gov> wrote:

  
There are already
middleboxes on the market today that do this. They
work for all outgoing connections and don't require
any cooperation whatsoever from the outside servers
that the clients are trying to connect to, and only
expert users would notice the presence of the MiTM.
  


They are also quite
  expensive because they have to generate certs on the fly.
    If you look at environments where these are in use, they
  tend to be either high-margin, or else low-use.   So e.g.
  you only redirect TLS connections that you absolutely need
  to intercept through the box; other connections are
  terminated normally.   Practically speaking, I don't see
  any cash-strapped school spending money on one of these
  devices.
  

  
  
  BTW, if you find this argument unconvincing,
consider why these boxes aren't being proposed for use as an
alternative to draft-rhrd-tls-tls13-visibility-00.   :)
  
  



  


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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[David A. Cooper]

Why would these schools settle for a half measure that only allows them 
to snoop on traffic between their students and servers provide the keys 
to their Internet traffic to the schools? If a school wants to snoop on 
its students' traffic, it would do so in a much easier way than using 
draft-rhrd-tls-tls13-visibility, in the same way that some enterprises 
today use middleboxes to inspect all outgoing traffic.


This browser that students would be required to use would be one that 
has a CA controlled by the middlebox installed as a trust anchor. 
Whenever one of the students' clients tries to connect to an external 
secure site, the middlebox-controlled CA issues a certificate for that 
site so that the connection can be terminated at the middlebox. The 
middlebox then establishes a secure connection with the end server, thus 
setting up the middlebox as a MiTM.


There are already middleboxes on the market today that do this. They 
work for all outgoing connections and don't require any cooperation 
whatsoever from the outside servers that the clients are trying to 
connect to, and only expert users would notice the presence of the MiTM.


Given that such an effective and simple-to-implement solution is already 
available today, why would these schools be so anxious to use a 
complicated-to-implement and largely ineffective solution such as 
subverting draft-rhrd-tls-tls13-visibility for improper purposes?


On 10/24/2017 03:36 PM, Yoav Nir wrote:

On 24 Oct 2017, at 22:27, Ralph Droms  wrote:



On Oct 24, 2017, at 3:23 PM, Salz, Rich  wrote:

I use an airplane as an example of a “captive” population, substitute any 
similar group you want.

• Yes, any box that sits between the client and the server can drop 
traffic for whatever reason it wants. Such a box could today drop any traffic 
that is protected using TLS.

True, but that’s not the point.  The point is by adding this extension into the 
clientHello, we are providing middleboxes with another knob to control traffic. 
 I think we want to avoid that. And keep in mind it’s not just HTTP, but *any* 
TLS-using traffic, such as many VPN’s.  It wouldn’t necessarily enable spying, 
but it could be used to guarantee that all traffic is amenable to spying.

As for how would such clients get promulgated?  Some simple scenarious include 
“surf for free on your flight, but use our Chromium-based browser to do so, 
available for free here.”How many people on the plane would click and 
download?

Just to make sure I understand, in this scenario the special-purpose browser 
could just as easily, today, be a browser with no TLS at all?   That is, I 
don't see why this scenario is specific to the visibility extension.

Think of the children.

We can’t just let them loose on the Internet, there’s predators out there. So 
we will snoop on their traffic.  To do that, we block all traffic that isn’t 
snoopable, and we do it at the edge router in schools.  All schools in our 
state are required by law to install a firewall that does this. And we get the 
mobile operators to do so as well (only for handsets in schools).

Now either the mobile OS vendors make a browser that works in schools (at least 
with a setting), or the school recommends a third party browser that works in 
school. And best of all, this is *more secure* than regular TLS 1.3, because it 
also protects your children from Internet predators. Think of the children.

You can’t make a claim like that for an HTTP-only browser, and worse still, it 
won’t work on much of today’s Internet.

Yoav



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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[David A. Cooper]

  
  

With this extension, any middlebox anywhere
  can drop traffic that is not tappable.  Regardless of who controls
  the clients and servers, we are now enabling entities to block
  traffic unless you acquiesce. For example, an inflight wifi could
  use this.  Maybe, ultimately, many/most of the servers that the
  passengers connect to will not support it, but some might.


Rich,

You've brought up this example of in-flight WiFi and other
middleboxes on the Internet uses this extension as a means of
coercing individuals into allowing their TLS traffic with servers to
be intercepted, but I fail to see how the scenario is at all
realistic.

Yes, any box that sits between the client and the server can drop
traffic for whatever reason it wants. Such a box could today drop
any traffic that is protected using TLS.

In order for a middlebox to be able to use this draft to intercept
traffic that is TLS protected, it would need to:

1) get the server to agree to allow it to intercept the traffic; and

2) get the client to include the new extension in its ClientHello.

How would the middlebox get the client to include the extension. You
previously said:
I believe I know why people want this now.
  They are worried that if TLS 1.3 goes out without something like
  this, then the market (standard widely available browsers) will
  not implement it. Let me assure you that this isn’t an issue. The
  extension would *never ever* make it to the MUST state, and the
  browsers would be unlikely to ever implement it anyway.

I partially agree with this and partially disagree. I agree that
browsers (and other similar clients) would be unlikely to ever
implement it. I disagree with the suggestion that proponents of this
draft want for browsers to implement this or want it to be a MUST.
Proponents of this draft are interested in visibility within the
data center, and have no interest in using this capability in any
scenario in which a browser would be the client.

So, given your agreement that browsers would be unlikely to ever
implement this extension, how would the in-flight WiFi (or other
middlebox) be able to get clients to include the extension if the
software they are using doesn't support it? It seems that the only
way would be to coerce the clients into using a browser (or other
client) provided by the attacker (i.e., in order to use the Internet
while in flight you must install Evil Airline's browser/app). But
then, if the attacker is able to get the client to install and use
its own software, then it would easily be able to intercept all
traffic from the client, not just traffic to cooperating servers, so
why would it bother using this draft at all in this case?



  


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