Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Martin Thomson]

On 21 November 2016 at 14:13, Eric Rescorla  wrote:
>> IMO, the compression methods section of ClientHello should be ignored as
>> mentioned by Martin Rex.
>
> I'm not seeing any good reason for this. We don't want anyone to offer
> compression and it's not
> like it's difficult for 1.3 implementations to not offer it.

I understand Martin Rex's rationale: we are effectively mandating a
requirement on implementations of other versions of the protocol.
However, I agree with ekr.  We have - I think - consensus to forbid
compression more broadly than just in TLS 1.3.  It's a foot gun.

And I don't believe that the foot gun is unique to the web case.  For
example, if you don't believe that mail could contain
attacker-controlled data and secrets, then you haven't thought hard
enough about all the ways mail can be used.  Similarly, insert
protocol of choice.  Of course it's definitely true that someone
loaded and cocked the footgun for the web.

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Eric Rescorla]

On Sun, Nov 20, 2016 at 5:42 PM, Yuhong Bao 
wrote:

> I can't help but notice the text:
> "Versions of TLS before 1.3 supported compression with the list of
> supported compression methods being sent in this field. For every TLS 1.3
> ClientHello,  this vector MUST contain exactly one byte set to zero, which
> corresponds to the “null” compression method in prior versions of TLS. If a
> TLS 1.3 ClientHello is received with any other value in this field, the
> server MUST abort the handshake with an “illegal_parameter”  alert. Note
> that TLS 1.3 servers might receive TLS 1.2 or prior ClientHellos which
> contain other compression methods and MUST follow the procedures for the
> appropriate prior version of TLS."
> IMO, the compression methods section of ClientHello should be ignored as
> mentioned by Martin Rex.


I'm not seeing any good reason for this. We don't want anyone to offer
compression and it's not
like it's difficult for 1.3 implementations to not offer it.


It may be too late for that, but RC4 IMO should be a SHOULD NOT not a MUST
> NOT.
> One reason for that is that it is not broken the way that say 56-bit
> encryption is.
>

The IETF has already decided this issue:
https://tools.ietf.org/rfcmarkup?doc=7465

-Ekr



> From: TLS  on behalf of Joseph Salowey <
> j...@salowey.net>
> Sent: Wednesday, October 26, 2016 7:56 PM
> To: tls@ietf.org
> Subject: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
>
>
> This is a working group last call announcement
> for draft-ietf-tls-tls13-18, to run through November  20. If possible,
> we would like to receive comments on the list by November 13 so  they
> can be discussed at the meeting in Seoul. We hope to address
> any substantive issues raised during that process shortly thereafter.
>
>
> In order to allow for cryptographic review, we will delay submission of
> the draft to the IESG until the end of January 2017; there will be an
> opportunity to address  any issues discovered by the cryptographic
> community prior to submission to the IESG.
>
>
> Cheers,
>
>
> Joe
>
>
> ___
> 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] Working Group Last Call for draft-ietf-tls-tls13-18

[Yuhong Bao]

I can't help but notice the text:
"Versions of TLS before 1.3 supported compression with the list of supported 
compression methods being sent in this field. For every TLS 1.3 ClientHello,  
this vector MUST contain exactly one byte set to zero, which corresponds to the 
“null” compression method in prior versions of TLS. If a TLS 1.3 ClientHello is 
received with any other value in this field, the server MUST abort the 
handshake with an “illegal_parameter”  alert. Note that TLS 1.3 servers might 
receive TLS 1.2 or prior ClientHellos which contain other compression methods 
and MUST follow the procedures for the appropriate prior version of TLS."
IMO, the compression methods section of ClientHello should be ignored as 
mentioned by Martin Rex.

It may be too late for that, but RC4 IMO should be a SHOULD NOT not a MUST NOT.
One reason for that is that it is not broken the way that say 56-bit encryption 
is.

From: TLS  on behalf of Joseph Salowey 
Sent: Wednesday, October 26, 2016 7:56 PM
To: tls@ietf.org
Subject: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
  

This is a working group last call announcement for draft-ietf-tls-tls13-18, to 
run through November  20. If possible, we would like to receive comments on the 
list by November 13 so  they can be discussed at the meeting in Seoul. We hope 
to address any substantive issues raised during that process shortly thereafter.


In order to allow for cryptographic review, we will delay submission of the 
draft to the IESG until the end of January 2017; there will be an opportunity 
to address  any issues discovered by the cryptographic community prior to 
submission to the IESG.


Cheers,


Joe

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[John Mattsson]

(This is the same comments as yesterday, just resending them as my mail
client turned my text into an unreadable mess, hopefully this is better).


Hi,

Very well written draft and an excellent protocol. The things I have found
is mostly editorial. I think it’s ready. I will try to make sure that 3GPP
already next year mandates support of both TLS 1.3 and DTLS 1.3 in all the
places they use (D)TLS.

Cheers,
John


- I cannot find any text describing the requirements TLS 1.3 put on the
  lower layers. In fact the only text I can find is "which might be hidden
  by TCP". I don't know if the draft should mandate TCP or not, but
  otherwise it should be stated that reliable, in-order transport is
  required, and that the lower layers must allow identification TLS
  messages in the same session (e.g. the 5-tuple when TCP is used).

- I cannot find any text describing that TLS 1.3 outputs a stream identical
  to the inputstream. The current text only states that the input on the
  sender side is application messages. Should state that the TLS is
  reliable and in-order.

- The are no requirements on the TLS API. I think the following should be
  added:
  - SHALL support an exporter API
  - SHALL support an API allowing application to get information regarding
the negotiated connection.
  - SHOULD support an API allowing application to influence the connection
to be negotiated.

- TLS 1.3 also updates RFC5246, but I don't know if you can both update and
  obsolete. If you have to choose, obsolete is better.

- Section 1: This is the only place channel is used in the meaning
  connection. I suggest "channel" -> "connection" as connection is used in
  the rest of the document.

- Section 1: "The TLS standard, however, does not specify ... how to
  interpret the authentication certificates"

  I don't this is really true any more, the draft has significant text on
  certificates. I suggest removing "how to interpret the authentication
  certificates exchanged"

- Figure 1, 4: "pre_shared_key_modes" -> "psk_key_exchange_modes"

- Figure 1. "Server Params" not horizontally aligned with "Key Exch" and
  "Auth" (not sure if this is a feature or a bug).

- Section 2: 
  "CertificateVerify:  a signature over the entire handshake "
  "Finished :  a MAC over the entire handshake "

  Not really true. Maybe add something like "to this point"

- Section 2: The text below Figure 1 should mention psk_key_exchange_modes.
  It talks about all other messages and extensions.

- Section 2.2: OLD "PSKs can be used with (EC)DHE exchange"
   NEW "PSKs SHOULD be used with (EC)DHE exchange"

- Section 2.3: 
  "When PSKs are provisioned out of band, the PSK identity and the KDF to
  be used with the PSK MUST also be provisioned."

  OLD "and the KDF to be used"
  NEW "and the Hash algorithm to be used"
  
  I think this is a little problematic as current PSK provisioning
  mechanisms do not provision a hash algorithm. This means that they need
  to be updated before TLS 1.3 can be used. Otherwise the risk is that one
  endpoint uses SHA-256 and the other SHA-384. To enable PSK systems to
  directly and easily upgrade to TLS 1.3 I suggest the following

  OLD
  "When PSKs are provisioned out of band, the PSK identity and the KDF to
  be used with the PSK MUST also be provisioned."

  NEW
  "When PSKs are provisioned out of band, the PSK identity MUST also be
  provisioned and the Hash algorithm to be used SHOULD be provisioned. If
  no hash algorithm has been provisioned, then SHA-256 SHALL be used."
  
  This would also affect 4.2.6.

- Section 2.3: "the following additional information MUST be provisioned to
  both parties:

   -  The Application-Layer Protocol Negotiation (ALPN) protocol, if any
  is to be used

   -  The Server Name Indication (SNI), if any is to be used"

  I think these two bullets apply to ALL uses of TLS. Or? I suggest moving
  to a general section.

- Section 2.3: "1.  This data is not forward secret, as it is encrypted
  solely under keys derived using the offered PSK."

  This is true for all uses of PSK without (EC)DHE and not only Zero-RTT. I
  suggest moving this text to another more general section. Maybe in
  Section 2 when the three basic key exchange modes are discussed.

- Section 2.3: Zero-RTT with PSK obtained out-of-band is a special case of
  Zero-RTT, with its own requirements and warnings. I think it should be
  moved to its own subsubsection (2.3.1).

- Section 3.5: "enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;"
  The variable 'n' is used for two different purposes. Use n, m or
  something.

- Section 3.8: Same thing here. The variable 'n' is used for two different
  purposes.

- Section 4.0 The cases in Handshake definition in some random order.
  Should keep the same order as the HandshakeType definition.

- Section 4.1.2 "Including a "cookie" extension if one was provided in the
  HelloRetryRequest."
  Could state that this is the HelloRetryRequest cookie echoed 

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Kaduk, Ben]

Unfortunately, Outlook seems to be incapable of properly quoting a message for 
inline replies, so I will have to top-post with the relevant bits.

I’ll try to put together some text on side-channel resistance along with my 
pull request for editorial changes.

With respect to psk_key_exchange_modes, PreSharedKey and KeyShare are enough 
for the existing modes, but my understanding was that the plan with splitting 
the modes out this way was to allow adding new modes in later documents, 
including PSK for server authentication.  Can we guarantee that for all future 
modes we might add, there will be some other extension that indicates what was 
picked?  (I guess we can probably arrange for that to happen with how we 
specify the new modes, so it’s not actually a big deal, but might or might not 
make things more awkward in the future.)

The problematic text about ciphertext length/expansion for tag and other things 
was in the description of the TLSCiphertext ‘length’ field, which says:

   length  The length (in bytes) of the following
  TLSCiphertext.fragment, which is the sum of the lengths of the
  content and the padding, plus one for the inner content type.  The
  length MUST NOT exceed 2^14 + 256.  An endpoint that receives a
  record that exceeds this length MUST terminate the connection with
  a "record_overflow" alert.

(There is no TLSCiphertext.fragment field.)  Assuming it’s talking about the 
length of the “opaque encrypted_record[length]” member (which seems obvious), I 
do not see how the length is the sum of the length of the (plaintext) content 
and padding and content-type octet, since the AEAD-encryption is supposed to 
add some amount of expansion.  Probably the answer is to just remove any 
discussion about what the length represents, since it is not really helping 
anything; the specification for the AEAD in use will specify the ciphertext 
length.

On 11/14/16, 10:44, "Eric Rescorla"  wrote:



On Mon, Nov 14, 2016 at 8:54 AM, Kaduk, Ben 
 wrote:

I have reviewed this document and have a few minor comments.  I also have 
many editorial notes that can be addressed out of band.

In the abstract and introduction, we have text about the properties that 
TLS is expected to provide, like confidentiality, authentication, etc.  Do we 
want to say anything about avoiding side channels that might leak information 
about the data being exchanged? 
 I know that we are not 100% confident at what exactly we currently achieve 
in this area, but since we have mechanisms that attempt to achieve it, maybe it 
is worth mentioning.  (In a similar vein, as davidben reminded me recently, an 
attacker “who has complete
 control of the network”, as is our stated adversary, can do things like 
trickle packets in one by one and try to see, e.g., where the end of early data 
is and query handshake state.  So some things may not be avoidable.)




I'd be interested in seeing a PR in this area.





In section 4.2.5.1 we talk about how for FFDH peers SHOULD validate each 
other’s public key Y by ensuring that 1 < Y < p-1, which is supposed to ensure 
that the peer is well-behaved and isn’t forcing the local system into a small 
subgroup.  Somehow I thought
 that additional checks were needed to avoid being forced into a small 
subgroup, but I guess that depends on what group it’s in, and I didn’t pull up 
the RFC 7919 reference when I was reading this document.




These are the recommendations in 7919, I believe




In section 4.2.7, we note that the server MUST NOT send the 
“psk_key_exchange_modes” extension, with the implication that the client must 
observer the types of handshake messages that are subsequently received in 
order to determine what the server selected. 
 I think that we had talked about this already some time ago, but just 
wanted to confirm that we are okay with increasing the size of the client state 
machine in this manner.




It's not subsequent messages. You determine it from the PreSharedKey and 
KeyShare extensions.




In section 4.5.1 we note that when client auth is not used, servers MAY 
compute the remainder of the client-sent messages for the transcript so as to 
issue a NewSessionTicket immediately after the server Finished.  Do we want to 
say anything about why a server
 might wish to do so?




I think I would rather not.





The coverage of record payload protection (around section 5.2) seems to not 
always make careful distinction between TLSPlaintext, TLSCiphertext, 
TLSInnerPlaintext, and the fields therein.  In some sense this is editorial, 
but there were a lot of places that
 I flagged, so I wanted to call it out to the broader audience and get more 
eyes on it.  I also didn’t find a 

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Eric Rescorla]

On Mon, Nov 14, 2016 at 8:54 AM, Kaduk, Ben  wrote:

> I have reviewed this document and have a few minor comments.  I also have
> many editorial notes that can be addressed out of band.
>
> In the abstract and introduction, we have text about the properties that
> TLS is expected to provide, like confidentiality, authentication, etc.  Do
> we want to say anything about avoiding side channels that might leak
> information about the data being exchanged?  I know that we are not 100%
> confident at what exactly we currently achieve in this area, but since we
> have mechanisms that attempt to achieve it, maybe it is worth mentioning.
> (In a similar vein, as davidben reminded me recently, an attacker “who has
> complete control of the network”, as is our stated adversary, can do things
> like trickle packets in one by one and try to see, e.g., where the end of
> early data is and query handshake state.  So some things may not be
> avoidable.)
>

I'd be interested in seeing a PR in this area.


In section 4.2.5.1 we talk about how for FFDH peers SHOULD validate each
> other’s public key Y by ensuring that 1 < Y < p-1, which is supposed to
> ensure that the peer is well-behaved and isn’t forcing the local system
> into a small subgroup.  Somehow I thought that additional checks were
> needed to avoid being forced into a small subgroup, but I guess that
> depends on what group it’s in, and I didn’t pull up the RFC 7919 reference
> when I was reading this document.
>

These are the recommendations in 7919, I believe


> In section 4.2.7, we note that the server MUST NOT send the
> “psk_key_exchange_modes” extension, with the implication that the client
> must observer the types of handshake messages that are subsequently
> received in order to determine what the server selected.  I think that we
> had talked about this already some time ago, but just wanted to confirm
> that we are okay with increasing the size of the client state machine in
> this manner.
>

It's not subsequent messages. You determine it from the PreSharedKey and
KeyShare extensions.


> In section 4.5.1 we note that when client auth is not used, servers MAY
> compute the remainder of the client-sent messages for the transcript so as
> to issue a NewSessionTicket immediately after the server Finished.  Do we
> want to say anything about why a server might wish to do so?
>

I think I would rather not.


The coverage of record payload protection (around section 5.2) seems to not
> always make careful distinction between TLSPlaintext, TLSCiphertext,
> TLSInnerPlaintext, and the fields therein.  In some sense this is
> editorial, but there were a lot of places that I flagged, so I wanted to
> call it out to the broader audience and get more eyes on it.  I also didn’t
> find a description of where the length of the AEAD authentication tag gets
> included into a length field for the ciphertext.
>

I'm not following this point. The way to think about this is that the
ciphertext is a specific size. That may be encryption + auth tag or not
(it's possible to design an AEAD algorithm that doesn't have a separate
auth tag).

-Ekr

At the end of section 6.1 we have this little note that “it is assumed that
> closing a connection reliably delivers pending data before destroying the
> transport”, which, if I remember correctly previous discussion on this
> list, is not actually true for linux.  It is perhaps problematic to have an
> assumption that we know is not going to be held for a large proportion of
> implementations.
>
> -Ben
>
> ___
> 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] Working Group Last Call for draft-ietf-tls-tls13-18

[Peter Gutmann]

Martin Rex  writes:

>There is a concept called "provable correctness", 

The problem with provable whatever is that it merely proves that, as far as
the provers can tell, the thing they're dealing with conforms to some abstract
model.  I don't think you can prove much about whatever hiding the ContentType
is supposed to achieve because there's no model for it that says, for example,
"for an attacker with these capabilities, under these conditions, the
following security guarantees are provided".

However, we do have a pile of empirical data showing that pretty much any
seems-like-a-good-idea traffic-hiding really only works until the moment
someone tries to attack it.  The best reference for this is "Peek-a-Boo, I
Still See You: Why Efficient Traffic Analysis Countermeasures Fail" by Dyer et
al.  So at the moment I'd say that if there's some measure that's completely
free (no downsides for anything else) then you may as well apply it because it
can't make things any worse, but not to say "let's do X because it seems like
a good idea" when it has no empirically-demonstrable benefit but lots of
drawbacks.

And it's the "empirically-demonstrable" that's important, Peek-a-Boo is chock
full of examples of things that seemed like a good idea but that don't
actually provide much, if any, benefit, while at the same time introducing all
sorts of downsides.

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Salz, Rich]

> There is a concept called "provable correctness", and folks (such as those

Hm, your arguments against it are that heuristics will expose the information 
anyway.

Has provability advanced far enough to include that concept?

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Benjamin Kaduk]

On 11/10/2016 11:13 AM, Martin Rex wrote:
>
> There is a concept called "provable correctness", and folks (such as
> those from the miTLS implementation) are using this approach to check/prove
> whether TLS provides certain security properties (rather than just
> assuming that these properties are provided).
>
> If hiding of ContentType has *real* value, then this property will be
> formally provable.  If the properties that someone asserts as value
> can be proven to not exist (one counterexample is sufficient),
> then the value is an illusion / obscurity, and definitely not real value.
>
>


My understanding was that our current knowledge of what capabilities
traffic analysis makes possible and the countermeasures against them is
quite poor, certainly not to the level where rigorous proofs are
possible.  So, I fear we must be operating "in the dark" in this regard
for the near future.

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Martin Rex]

Benjamin Kaduk wrote:
[ Charset windows-1252 unsupported, converting... ]
> On 11/09/2016 11:42 AM, Martin Rex wrote:
> > Nobody so far has provide a single example of *REAL* value.
> > For the hiding of ContentType to provide real value, the prerequisites are:
> >
> >   (1) this value will be _unconditionally_ provided in TLSv1.3
> >
> >   (2) this value can be demonstrated to be a real security issue in TLSv1.2,
> >   for existing usage scenarios, where hiding of ContentType is not
> >   available
> >
> > Anyhing less is no value, just an illusion of value.
> 
> Thanks for clarifying your position.  I don't think many of the other
> people in the thread are using the same definition of "value", which has
> led to a lot of confusion.
> 
> However, I'm not convinced that the concrete benefit needs to be
> mandatory-to-use in TLS 1.3 to be considered to provide value.


There is a concept called "provable correctness", and folks (such as
those from the miTLS implementation) are using this approach to check/prove
whether TLS provides certain security properties (rather than just
assuming that these properties are provided).

If hiding of ContentType has *real* value, then this property will be
formally provable.  If the properties that someone asserts as value
can be proven to not exist (one counterexample is sufficient),
then the value is an illusion / obscurity, and definitely not real value.


-Martin

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Martin Rex]

Eric Rescorla wrote:
> 
> I'm not quite following who's who in this scenario, so some potentially
> stupid
> questions below.
> 
> As I understand it, you have the following situation:
> 
> - A Web application server
> - Some middleware, which comes in two pieces
>   - A crypto-unaware network component
>   - The TLS stack (you control this piece as well, right?)
> - The client

This is about any conceivable scenario involving at least one of our
components, just client, just server, or at both peers.

The "middleware" is part of our clients and servers. The middleware
performs all the network I/O and necessary calls into the TLS stack,
offers an appdata streaming convenience option for reading,
variable blocking I/O (non-blocking (0ms) up to infinite timeout).

TLS records of type Handshake, Alert and CCS are always processed
in batch, as many as the network buffers have already received.
TLS records of type AppData are processed based on read strategy
desired by the application caller.  The desired reading strategy
(trickling, efficient, streaming) is a parameter of the middleware
read API call, so the app could change it for every call.

 - Trickling means the traditional TLS record reading, i.e. two network
   read calls for every TLS record.

 - Improved means on average one network read call per TLS record.

 - Streaming means reading and decoding as many TLS appdata record
   as there are present in the network read buffers and can be
   received non-blocking.  Only TLS AppData records will be passed
   to the TLS Stack for decoding, Alerts and Handshake records
   will be left in the middlewares network read buffers until all
   appdata as been properly received by the application caller.
   Only upon the next read call from the application, the alert
   or handshake records will be passed to the TLS stack.

Example: GET https://www.google.de/ HTTP/1.0
(where my call to www.google.com is redirected to...)

currently returns a HTTP-response with a 657 byte Header and 44879 byte Body
The response would easily fit into 3 TLS appdata records
(4 Records if the Header is sent in its own TLS record), however
in reality, the Google servers perform pathological fragmentation
of the AppData and use a whooping 36 TLS records for the response
(curiously no TLS AppData record split between header and body).


Processing overhead for _receiving_ such a badly fragmented response:

Trickling:
  34 Read calls into the middleware
  73 recv() calls to read the TLS AppData records from the socket
  34 calls into the TLS stack

Improved:
  34 Read calls into the middleware
  42 recv() calls to read the TLS AppData records from the socket
  34 calls into the TLS stack

Streaming:
   5 Read calls into the middleware
  14 recv() calls to read the TLS AppData records from the socket
  34 calls into the TLS stack
   



>
> When do you deliver the close_notify and how do you know how?

When the application calls for read, and has already seen all
prior AppData, then the close_notify will be processed and the
result (connection closure, no more data) reported to the calling app.

There is no magic involved here.

Apps *know* when to perform reads, and when not to perform reads.
The middleware doesn't because it is protocol ignorant (it is used
by SMTP, ldaps, HTTPS, HTTP/2.0, websockets, etc).

Think of a simple HTTP-based server app receiving a HTTP/1.0 request
from a TLS-stack on top of a blocking network socket.  If the App would
keep calling SSL_read() (for an OpenSSL-style API), it would get stuck
(blocked on read), and at some point the client would give up and
close the connection (with close_notify or TCP RST), and the server
waking from either the processing of the close_notify or the TCP RST
would be unable to deliver a response (which the client would not read
anyway).

Whether or not the calling App wants to shutdown a communication
at different times in both directions depends on the existing semantics
of that application (which has just added TLS protection around its
communication).  Reading and processing a close_notify in the TLS stack
(e.g. OpenSSL) will tear down *BOTH* directions immediately, and preclude
any further of sending of responses by the application, so the middleware
really will want to hold of processing of close_notify alerts unless
_explicitly_ asked to read further AppData by the application.

With TLS up to TLSv1.2 streaming is no problem, the middleware can
easily recognize non-AppData records and avoid passing them to
the TLS stack for processing unless the application explicitly asks
the middleware to do so.  When TLSv1.3 hides the ContentType,
the fact that a close_notify was received & processed can only be
determined after the fact, when the shattered pieces are on the floor.
Communication in the other direction will be impossible, and it will
not be possible to prevent this from happening.

While it is conceivable to jump hoops and implement new APIs and
callback for the TLS stack 

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Martin Rex]

Daniel Kahn Gillmor wrote:
>
> Martin Rex wrote:
>>
>> The problem here is that this breaks (network) flow control, existing
>> (network socket) event management, and direction-independent connection
>> closure, and does so completely without value.
> 
> Martin, you keep saying things like "without value", while other people
> on this thread (Rich, Ilari, Yoav) have given you examples of the value
> it provides.  You don't seem to be trying to understand those positions.

Nobody so far has provide a single example of *REAL* value.
For the hiding of ContentType to provide real value, the prerequisites are:

  (1) this value will be _unconditionally_ provided in TLSv1.3

  (2) this value can be demonstrated to be a real security issue in TLSv1.2,
  for existing usage scenarios, where hiding of ContentType is not
  available

Anyhing less is no value, just an illusion of value.


> 
> This WG isn't chartered to defend the engineering optimizations made by
> any particular middlebox vendor.  It's chartered to improve the privacy
> and security guarantees offered to users of TLS.

You are confusing _middlebox_ with _middleware_at_the_endpoint_,
which is a huge difference, because the middleboxes are performing
man-in-the-middle attacks, whereas the _middleware_at_the_endpoint_
has regular access to the entire plaintext of the communication.

The problem with hiding of TLS record ContentTypes is that it severely
interferes with efficient streaming network I/O--which is preferably
performed outside/above the TLS implementation and async non-blocking
whenever you get into thousands of parallel connections.


-Martin

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Daniel Kahn Gillmor]

On Wed 2016-11-09 03:31:22 -0600, Martin Rex wrote:
> The problem here is that this breaks (network) flow control, existing
> (network socket) event management, and direction-independent connection
> closure, and does so completely without value.

Martin, you keep saying things like "without value", while other people
on this thread (Rich, Ilari, Yoav) have given you examples of the value
it provides.  You don't seem to be trying to understand those positions.

Your description of the problems it causes you are difficult to follow,
and it doesn't sound like they have been experienced by other
implementors.  But other people are actively trying to make sure they
understand your concerns (like ekr's post downthread here).

Could you offer the rest of the list the same courtesy?

Your earlier argument that the hidden data is deducable by traffic
analysis anyway isn't a satisfying argument, for two reasons:

(a) if it were reliably true, then your implementations could simply
adopt the traffic analysis approach instead of inspecting the
cleartext content types.  If it causes too much additional expense,
then it should increase the expense for adversaries who are
monitoring traffic for these same signals as well, which is a
security+privacy win.

(b) We're including mechanisms (like padding) to make traffic analysis
harder.  More research is needed to know how to best provide this
sort of indistinguishability.  But if we decide instead that it's ok
to directly publish any data that could possibly be inferred by
traffic analysis, we will never improve the security of TLS for its
users against traffic analysis, which will only grow more
sophisticated over time.  Why should we accept this limitation on
TLS?

This WG isn't chartered to defend the engineering optimizations made by
any particular middlebox vendor.  It's chartered to improve the privacy
and security guarantees offered to users of TLS.

Regards,

 --dkg


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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Salz, Rich]

> the PDUs are still pretty much predictable
> heuristically (by their ordering), even when they're padded.

...
 
> So besides being completely pointless, can you describe any realistic problem
> that is worth breaking middleware at the endpoints so badly?

I found the language difference interesting.  We could conduct an interesting 
thought experiment by reversing the emphasis on each of the above fragments.  
But I won't.

Instead, I'll point out that this is in-charter, in-scope, and WG consensus has 
generally been to "encrypt all the bits" as much as feasible.

Some applications in some corners of some enterprises, might lose out.

Just like those who depending on static RSA, right?

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Ilari Liusvaara]

On Thu, Nov 03, 2016 at 08:38:32PM +0200, Yoav Nir wrote:
> 
> > On 3 Nov 2016, at 20:20, Martin Rex  wrote:
> > 
> > -- so why would we need a backwards-incompatible change in a
> > protocol that protects something that no longer exists,
> > but which severely breaks existing middleware, making it
> > impossible to drop-in replace a TLSv1.2 implementation with
> > a TLSv1.3 implementation that has this backwards-incompatibility.
> 
> Can you elaborate on that middleware?

Also, what platform (Java? .NET? Linux?) does that middleware run on,
and some base interfaces from standard library (or widespread
extensions) it uses for its API...


What I think I gathered from the description (and this sounds very
bizarre):

- Upon new data indication, the middleware peeks TLS header from the
  incoming data buffer.
- If it is not appdata, it is read and handled.
- If it appdata, the socket readable indication is passed to the
  application (what supports that without wrapping the socket???)
  which it then reads (and presumably passes for decryption).


That sounds much more bizarre than the zerocopy APIs in btls (the
TLS lib I am working on), and those are already pretty odd.


-Ilari

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Yoav Nir]

> On 3 Nov 2016, at 20:20, Martin Rex  wrote:
> 
> Yoav Nir wrote:
>> 
>> On 3 Nov 2016, at 16:31, Martin Rex  wrote:
>>> 
>>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype,
>>> which has existed through SSLv3->TLSv1.2 would be a problem.  With the
>>> removal of renegotiation from TLSv1.3, it is even less of a problem to
>>> keep the contenttype in the clear.
>> 
>> Here?s some to get this to somewhat >0:
>> 
>> Most TLS 1.2 connections will have a few handshake records,
>> followed by a couple of CCS records followed by a whole bunch of
>> application records, followed possibly by a single Alert.
>> 
>> You only see more handshake records in two cases:
>>   1. The client decided to re-negotiate. That is exceedingly rare.
>>   2. The server decided a renegotiation is needed
>>  so it sent a HelloRequest followed by a handshake.
>> 
>> With visible content type, you can tell these two flows apart.
> 
> (a) so what?  for those interested, one can tell such flows appart
> pretty reliably by traffic analysis.  So there is exactly ZERO
> protection against bad guys, while breaking the good guys.

There is if you pad the records to the size of application records.

> (b) but TLSv1.2 remains unchanged, and this flow does not seem to
> exist in TLSv1.3, since renegotiation no longer exists in TLSv1.3.

Re-negoatiation doesn’t, but post-handshake client authentication does:
https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.5.2 


> -- so why would we need a backwards-incompatible change in a
> protocol that protects something that no longer exists,
> but which severely breaks existing middleware, making it
> impossible to drop-in replace a TLSv1.2 implementation with
> a TLSv1.3 implementation that has this backwards-incompatibility.

Can you elaborate on that middleware?

Yoav

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Benjamin Kaduk]

On 11/03/2016 01:15 PM, Martin Rex wrote:
> Salz, Rich wrote:
>>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype,
>>> which has existed through SSLv3->TLSv1.2 would be a problem.  
>> Because it's kind of implied in the charter, about making as much private as 
>> possible.
>>
>>> years), because it is actively being used to signal state of the 
>>> communication
>>> channel to the application and to *NOT* break application architecture that
>>> relies on (new) application data remaining visible on network sockets as
>>> "network readable" events.
>> One app's data is another adversary's oracle.
>> Or is it that "signals have no morals"?
> If you look at TLS records exchanged between two peers,
> and in particular if you perform a TLS handshake with same server
> yourself and compare, you can easily (heuristically) determine
> which TLS records of the original stream are hanshake records,
> and which are application data records.
>
> So there is exactly ZERO benefit of concealing the ContentTypes.
>
>

Sorry, but that doesn't directly follow. 

With visible content type, an observer can *trivially* tell apart the
two flows you mentioned in your next message.  With current stacks'
(lack of) padding and timing obfuscation, the observer can still tell
the flows apart ... but you have a chance of writing a stack that
prevents the observer from doing so.  I don't think that "goes from
'impossible' to 'you have to write code'" can be construed as exactly
zero benefit.

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Martin Rex]

Yoav Nir wrote:
> 
> On 3 Nov 2016, at 16:31, Martin Rex  wrote:
>> 
>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype,
>> which has existed through SSLv3->TLSv1.2 would be a problem.  With the
>> removal of renegotiation from TLSv1.3, it is even less of a problem to
>> keep the contenttype in the clear.
> 
> Here?s some to get this to somewhat >0:
> 
> Most TLS 1.2 connections will have a few handshake records,
> followed by a couple of CCS records followed by a whole bunch of
> application records, followed possibly by a single Alert.
> 
> You only see more handshake records in two cases:
>1. The client decided to re-negotiate. That is exceedingly rare.
>2. The server decided a renegotiation is needed
>   so it sent a HelloRequest followed by a handshake.
> 
> With visible content type, you can tell these two flows apart.

 (a) so what?  for those interested, one can tell such flows appart
 pretty reliably by traffic analysis.  So there is exactly ZERO
 protection against bad guys, while breaking the good guys.

 (b) but TLSv1.2 remains unchanged, and this flow does not seem to
 exist in TLSv1.3, since renegotiation no longer exists in TLSv1.3.
 -- so why would we need a backwards-incompatible change in a
 protocol that protects something that no longer exists,
 but which severely breaks existing middleware, making it
 impossible to drop-in replace a TLSv1.2 implementation with
 a TLSv1.3 implementation that has this backwards-incompatibility.

-Martin

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Martin Rex]

Salz, Rich wrote:
>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype,
>> which has existed through SSLv3->TLSv1.2 would be a problem.  
> 
> Because it's kind of implied in the charter, about making as much private as 
> possible.
> 
>> years), because it is actively being used to signal state of the 
>> communication
>> channel to the application and to *NOT* break application architecture that
>> relies on (new) application data remaining visible on network sockets as
>> "network readable" events.
> 
> One app's data is another adversary's oracle.
> Or is it that "signals have no morals"?

If you look at TLS records exchanged between two peers,
and in particular if you perform a TLS handshake with same server
yourself and compare, you can easily (heuristically) determine
which TLS records of the original stream are hanshake records,
and which are application data records.

So there is exactly ZERO benefit of concealing the ContentTypes.

But this concealing reliably breaks existing application middleware
at the endpoints, which needs to reliably & quickly tell the difference
between handshake records and application data, so that it can
leave application data records in the network buffer, so that the
socket readable event remains visible for the event-based application
logic.

-Martin

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Yoav Nir]

I don’t think this makes any difference in applications written on commodity 
servers using regular socket APIs.

It’s a kind of architecture that has a quick special purpose processor that 
terminates the TCP and splits the incoming stream into records. The application 
records are forwarded to a quick crypto processor that decrypts the records and 
feeds them into the application. Other types of records are forwarded to the 
handshake processor usually implemented on general-purpose hardware with 
perhaps a cryptographic accelerator for asymmetric operations. That performs 
the handshake and feeds the key to the application processor.

With the change in TLS 1.3, the TCP terminator can no longer tell the records 
apart. That means that the crypto processor will have to take on that duty. 
That’s a change in architecture that could require new hardware as opposed to a 
firmware update for existing hardware.

I tend to believe that if this had been such a big deal we would have heard 
from more people, but I could be wrong. It’s clear to me that the mid-sized 
content providers who are likely to use such architectures are not yelling much.

Yoav

> On 3 Nov 2016, at 19:30, Watson Ladd  wrote:
> 
> On Thu, Nov 3, 2016 at 7:31 AM, Martin Rex  > wrote:
>> Ilari Liusvaara wrote:
> 
> Hiding the types does have its benefits (and it is also used for
> zero-overhead padding scheme).
 
 Nope, ZERO benefits.  But it totally breaks the middleware
 _at_the_endpoints_!
>>> 
>>> Also, things like this should have been discussed like year or two
>>> ago. Right now it is too late for major changes like this without good
>>> cryptographic justifications (which AFAICT don't exist).
>> 
>> They WERE brought up back then, and several times in between.
>> But the TLSv1.3 proposal has still not been fixed so far.
>> Ignorance does not make problems go away.  Instead, it means that
>> one will have to fix it later.
>> 
>> 
>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype,
>> which has existed through SSLv3->TLSv1.2 would be a problem.  With the
>> removal of renegotiation from TLSv1.3, it is even less of a problem to
>> keep the contenttype in the clear.
>> 
>> The removal of visibility of ContentType in TLSv1.3 will be a complete
>> non-starter for TLSv1.3 as a drop-in replacement to TLSv1.2 for certain
>> software architectures (including a lot of stuff we've been shipping for the
>> last 5 years), because it is actively being used to signal state of
>> the communication channel to the application and to *NOT* break application
>> architecture that relies on (new) application data remaining visible on
>> network sockets as "network readable" events.
> 
> This I do not understand. I may make some technical errors in below,
> and would appreciate correction.
> 
> I assume we have an application that is using poll() or select() or
> somesuch for nonblocking IO (maybe something fancier, but that is
> okay).
> 
> This application grabs data from a ready connection, rams it through
> the TLS implementation, and then looks at what comes out. But reading
> from the connection clears the data available state! However, it's
> never the case that there is visible data absent a network read or
> write after the handshake.
> 
> So what is the content type doing here? Does the application not call
> a TLS implementation provided state function to determine what state
> the connection is in? And if so why does the record layer need to
> know, as opposed to the handshake one? I'm not seeing why the above
> style implementation is impossible: Microsoft doesn't seem to think so
> and hasn't complained about this change.
> 
> Sincerely,
> Watson Ladd
> 
> ___
> 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] Working Group Last Call for draft-ietf-tls-tls13-18

[Watson Ladd]

On Thu, Nov 3, 2016 at 7:31 AM, Martin Rex  wrote:
> Ilari Liusvaara wrote:

 Hiding the types does have its benefits (and it is also used for
 zero-overhead padding scheme).
>>>
>>> Nope, ZERO benefits.  But it totally breaks the middleware
>>> _at_the_endpoints_!
>>
>> Also, things like this should have been discussed like year or two
>> ago. Right now it is too late for major changes like this without good
>> cryptographic justifications (which AFAICT don't exist).
>
> They WERE brought up back then, and several times in between.
> But the TLSv1.3 proposal has still not been fixed so far.
> Ignorance does not make problems go away.  Instead, it means that
> one will have to fix it later.
>
>
> Since then, I've seen exactly ZERO rationale why the cleartext contenttype,
> which has existed through SSLv3->TLSv1.2 would be a problem.  With the
> removal of renegotiation from TLSv1.3, it is even less of a problem to
> keep the contenttype in the clear.
>
> The removal of visibility of ContentType in TLSv1.3 will be a complete
> non-starter for TLSv1.3 as a drop-in replacement to TLSv1.2 for certain
> software architectures (including a lot of stuff we've been shipping for the
> last 5 years), because it is actively being used to signal state of
> the communication channel to the application and to *NOT* break application
> architecture that relies on (new) application data remaining visible on
> network sockets as "network readable" events.

This I do not understand. I may make some technical errors in below,
and would appreciate correction.

I assume we have an application that is using poll() or select() or
somesuch for nonblocking IO (maybe something fancier, but that is
okay).

This application grabs data from a ready connection, rams it through
the TLS implementation, and then looks at what comes out. But reading
from the connection clears the data available state! However, it's
never the case that there is visible data absent a network read or
write after the handshake.

So what is the content type doing here? Does the application not call
a TLS implementation provided state function to determine what state
the connection is in? And if so why does the record layer need to
know, as opposed to the handshake one? I'm not seeing why the above
style implementation is impossible: Microsoft doesn't seem to think so
and hasn't complained about this change.

Sincerely,
Watson Ladd

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Salz, Rich]

> Since then, I've seen exactly ZERO rationale why the cleartext contenttype,
> which has existed through SSLv3->TLSv1.2 would be a problem.  

Because it's kind of implied in the charter, about making as much private as 
possible.

> years), because it is actively being used to signal state of the communication
> channel to the application and to *NOT* break application architecture that
> relies on (new) application data remaining visible on network sockets as
> "network readable" events.

One app's data is another adversary's oracle.  Or is it that "signals have no 
morals"?

/r$

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz


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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Martin Rex]

Ilari Liusvaara wrote:
>>> 
>>> Hiding the types does have its benefits (and it is also used for
>>> zero-overhead padding scheme).
>> 
>> Nope, ZERO benefits.  But it totally breaks the middleware
>> _at_the_endpoints_!
> 
> Also, things like this should have been discussed like year or two
> ago. Right now it is too late for major changes like this without good
> cryptographic justifications (which AFAICT don't exist).

They WERE brought up back then, and several times in between.
But the TLSv1.3 proposal has still not been fixed so far.
Ignorance does not make problems go away.  Instead, it means that
one will have to fix it later.


Since then, I've seen exactly ZERO rationale why the cleartext contenttype,
which has existed through SSLv3->TLSv1.2 would be a problem.  With the
removal of renegotiation from TLSv1.3, it is even less of a problem to
keep the contenttype in the clear.

The removal of visibility of ContentType in TLSv1.3 will be a complete
non-starter for TLSv1.3 as a drop-in replacement to TLSv1.2 for certain
software architectures (including a lot of stuff we've been shipping for the
last 5 years), because it is actively being used to signal state of
the communication channel to the application and to *NOT* break application
architecture that relies on (new) application data remaining visible on
network sockets as "network readable" events.



https://www.ietf.org/mail-archive/web/tls/current/msg13085.html

https://www.ietf.org/mail-archive/web/tls/current/msg13106.html


A similar issue exists for the visibility of Alert ContentTypes
for efficiently detecting client-side connection closure.
This has been described here:

https://www.ietf.org/mail-archive/web/tls/current/msg21123.html


The IETF technical leadership is supposed to prevent backwards-incompatible
changes to be adopted and standardized that provide *ZERO* benefit,
but severely impair interop and consumption.


-Martin

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Sean Turner]

The concern here is that people won’t review it until the end and that is 
definitely not what we want.  I’d really like get the most out of our f2f 
meeting in Seoul so pretty please people review it before Seoul.

spt

> On Oct 27, 2016, at 07:07, Salz, Rich  wrote:
> 
> So isn't it really a WGLC that runs until end of January 2017?
> 
> --  
> Senior Architect, Akamai Technologies
> Member, OpenSSL Dev Team
> IM: richs...@jabber.at Twitter: RichSalz
> 
> 
> ___
> 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] Working Group Last Call for draft-ietf-tls-tls13-18

[Martin Rex]

Ilari Liusvaara wrote:
> Martin Rex wrote:
>> Joseph Salowey wrote:
>> 
>> There are two seriously backwards-incompatible changes in the
>> current proposal that provide zero value, but completely break
>> backwards-compatibility with existing middleware infrastructure.
>> 
>> 
>> (1) hiding of the TLS record content types.
>> Please leave the TLS record types (handshake/AppData/Alert/CCS)
>> clearly visible on the outside of the TLS records, so that
>> middleware protocol parsers (which interface to transport-free
>> TLS protocol stacks) can continue to work, and continue to
>> work efficiently.
> 
> Hiding the types does have its benefits (and it is also used for
> zero-overhead padding scheme).

Nope, ZERO benefits.  But it totally breaks the middleware
_at_the_endpoints_!


> 
> And also, TLS 1.3 handshake is so darn different from TLS 1.2, that
> you couldn't do anything sane even if you had record types.

Wrong.

If one is using an architecture where the TLS protocol stack is
transportless, so that the network communication can be performed
efficiently (coalescing TLS records that are trickling in), then
the *REAL* content type is quite important for knowing whether
the TLS handshake is still ongoing, or whether it is already
complete.

The way I've built this is that the middleware has a timeout for
the TLS handshake in its entirety (independent of the number of
roundtrips), and at the same time promises the application a
network readable event for every incoming TLS record with
application data.  This only works if I can leave TLS appdata
records partially in the incoming network buffer, and for this
I must be able to recognize them.

For processing TLS records with Handshake messages, pre-reading and
passing multiple of them is preferable and much more efficient
(if TLS handshake messages come in seperate TLS records each, which
some implementations do).  Pre-reading TLS records with handshake messages,
but not prereading TLS records with AppData (so that network readable
events will remain visible for app data) is only possible if I see the
contents on the outside of the record by just reading the TLS record header.


-Martin

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Eric Rescorla]

On Sat, Oct 29, 2016 at 5:23 AM, Martin Rex  wrote:

> If the server_name remains in plaintext and full sight in ClientHello
> (where it needs to be for TLSv1.2 backwards compatibility anyway),
> then I don't have an issue.  (I'm sorry for not reading the draft in full)


Good to hear.


> Eric Rescorla wrote:
> >
> >> (2) hiding of the TLS extension SNI.
> >> Right now it is perferctly fine to implement TLS extensions SNI
> >> on the server completely outside the TLS protocol stack to route
> >> to single-cert SNI-unaware backends.  The current proposal
> >> suggest to move TLS extension SNI into the encrypted part, if
> >> my superficial reading of the draft is correct, so TLSv1.3
> >> will not fly with existing architectures where spreading of
> >> TLS requests on the server-side based on TLS extension SNI
> >> is done outside of the TLS protocol stack (i.e. bottleneck-less
> >> without having to open TLS).
> >
> >
> > This isn't quite right. In RFC 6066, the client sends its server_name
> > extension in ClientHello and the server responds with an empty
> > server_name in its ServerHello to indicate that it accepted SNI.
>
> Yes, I know that rfc6066 suggests the server responds with an empty SNI
> extension.  This kind of server response is is a complete waste,
> and server-side SNI works just fine with the server not returning
> an empty SNI extension.
>
>
> >
> >A server that receives a client hello containing the "server_name"
> >extension MAY use the information contained in the extension to guide
> >its selection of an appropriate certificate to return to the client,
> >and/or other aspects of security policy.  In this event, the server
> >SHALL include an extension of type "server_name" in the (extended)
> >server hello.  The "extension_data" field of this extension SHALL be
> >empty.
> >
> > In TLS 1.3, the client's extension remains where it is, but the server's
> > extension is in EncryptedExtensions. This shouldn't interfere with
> > configurations such as the one you describe, as the server already
> > needed to insert the SNI field itself and hash it into Finished.
>
> Nope, the server doesn't need to insert anything at all.  The empty
> TLS extensions SNI in ServerHello is completely superflouous.
>
> If this is really about "hinding the empty TLS extension SNI response",
> while leaving the actualy server_name in full sight in the cleartext
> ClientHello, why not just dropping the ServerHello TLS extension SNI
> response and be done with it?  It really has no functional value other
> than information discovery for scanners (the bad guys).
>

I would be fine with that if others are. Here's how we got here:

- RFC 6066 requires it (it's a SHALL level requirement).
- We didn't see a need to update the semantics of 6066
- Everything that doesn't have to be in ServerHello goes into EE.

If point #2 is wrong, then that's easy to change, though it would be a
change to
implementations. NSS, for instance, sends it:
http://searchfox.org/nss/source/lib/ssl/ssl3ext.c#436
-Ekr


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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Martin Rex]

If the server_name remains in plaintext and full sight in ClientHello
(where it needs to be for TLSv1.2 backwards compatibility anyway),
then I don't have an issue.  (I'm sorry for not reading the draft in full).


Eric Rescorla wrote:
> 
>> (2) hiding of the TLS extension SNI.
>> Right now it is perferctly fine to implement TLS extensions SNI
>> on the server completely outside the TLS protocol stack to route
>> to single-cert SNI-unaware backends.  The current proposal
>> suggest to move TLS extension SNI into the encrypted part, if
>> my superficial reading of the draft is correct, so TLSv1.3
>> will not fly with existing architectures where spreading of
>> TLS requests on the server-side based on TLS extension SNI
>> is done outside of the TLS protocol stack (i.e. bottleneck-less
>> without having to open TLS).
> 
> 
> This isn't quite right. In RFC 6066, the client sends its server_name
> extension in ClientHello and the server responds with an empty
> server_name in its ServerHello to indicate that it accepted SNI.

Yes, I know that rfc6066 suggests the server responds with an empty SNI
extension.  This kind of server response is is a complete waste,
and server-side SNI works just fine with the server not returning
an empty SNI extension.


> 
>A server that receives a client hello containing the "server_name"
>extension MAY use the information contained in the extension to guide
>its selection of an appropriate certificate to return to the client,
>and/or other aspects of security policy.  In this event, the server
>SHALL include an extension of type "server_name" in the (extended)
>server hello.  The "extension_data" field of this extension SHALL be
>empty.
> 
> In TLS 1.3, the client's extension remains where it is, but the server's
> extension is in EncryptedExtensions. This shouldn't interfere with
> configurations such as the one you describe, as the server already
> needed to insert the SNI field itself and hash it into Finished.

Nope, the server doesn't need to insert anything at all.  The empty
TLS extensions SNI in ServerHello is completely superflouous.

If this is really about "hinding the empty TLS extension SNI response",
while leaving the actualy server_name in full sight in the cleartext
ClientHello, why not just dropping the ServerHello TLS extension SNI
response and be done with it?  It really has no functional value other
than information discovery for scanners (the bad guys).


-Martin

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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Eric Rescorla]

On Sat, Oct 29, 2016 at 3:00 AM, Martin Rex  wrote:

> Joseph Salowey wrote:
> >
> > This is a working group last call announcement for
> draft-ietf-tls-tls13-18,
> > to run through November 20. If possible, we would like to receive
> comments
> > on the list by November 13 so they can be discussed at the meeting in
> > Seoul. We hope to address any substantive issues raised during that
> process
> > shortly thereafter.
> >
> > In order to allow for cryptographic review, we will delay submission of
> the
> > draft to the IESG until the end of January 2017; there will be an
> > opportunity to address any issues discovered by the cryptographic
> community
> > prior to submission to the IESG.
>
>
> There are two seriously backwards-incompatible changes in the
> current proposal that provide zero value, but completely break
> backwards-compatibility with existing middleware infrastructure.
>
>
> (1) hiding of the TLS record content types.
> Please leave the TLS record types (handshake/AppData/Alert/CCS)
> clearly visible on the outside of the TLS records, so that
> middleware protocol parsers (which interface to transport-free
> TLS protocol stacks) can continue to work, and continue to
> work efficiently.


I'll let the chairs determine how to handle this.



> (2) hiding of the TLS extension SNI.
> Right now it is perferctly fine to implement TLS extensions SNI
> on the server completely outside the TLS protocol stack to route
> to single-cert SNI-unaware backends.  The current proposal
> suggest to move TLS extension SNI into the encrypted part, if
> my superficial reading of the draft is correct, so TLSv1.3
> will not fly with existing architectures where spreading of
> TLS requests on the server-side based on TLS extension SNI
> is done outside of the TLS protocol stack (i.e. bottleneck-less
> without having to open TLS).


This isn't quite right. In RFC 6066, the client sends its server_name
extension in ClientHello and the server responds with an empty
server_name in its ServerHello to indicate that it accepted SNI.

   A server that receives a client hello containing the "server_name"
   extension MAY use the information contained in the extension to guide
   its selection of an appropriate certificate to return to the client,
   and/or other aspects of security policy.  In this event, the server
   SHALL include an extension of type "server_name" in the (extended)
   server hello.  The "extension_data" field of this extension SHALL be
   empty.

In TLS 1.3, the client's extension remains where it is, but the server's
extension is in EncryptedExtensions. This shouldn't interfere with
configurations such as the one you describe, as the server already
needed to insert the SNI field itself and hash it into Finished.

-Ekr


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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Salz, Rich]

So isn't it really a WGLC that runs until end of January 2017?

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz


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