Re: [TLS] TLS 1.3, how to close the read side of a connection?

[Tony Putman]

David,

I think this is a valid concern. It's been commented on 
(https://www.ietf.org/mail-archive/web/tls/current/msg25579.html) that the 
draft has NO requirements on the underlying transport. There are potentially 
other transports for TLS (such as being worked by the ATLAS WG) which may not 
have a way to terminate the transport.

At a minimum this must be addressed in DTLS, but it seems to me that the 
addition of a close_request alert is a small matter which would benefit both 
protocols. Of course, this could be added at a later date if/when the need 
arises.

Regards,
Tony

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Xuelei Fan
Sent: 07 March 2018 20:54
To: David Schinazi
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3, how to close the read side of a connection?

Hi David,

The case I can think of now is the START TLS protocols (Opportunistic TLS).  
But looks like these protocols need to use an existing plain-text socket, and 
then establish a TLS connection over it, and will never go back to plain-text 
again.  Maybe, for START TLS protocols, closing TLS connection just implies 
close the underlying TCP socket in practice.  We don't do that previously as we 
don't know how the  plain-text socket can be used in practice in the follow on 
processes after TLS get closed (while socket still alive).   If an application 
gets indication that the TLS connection get closed, it can use the cleanup 
socket.  So it does not actually need to understand the TLS specifics.

I'm a little bit hesitate if there is a reality user case for such requirement. 
 Maybe, I can just close the socket, and see what the compatibility impact 
could be.

Thanks,
Xuelei

On Wed, Mar 7, 2018 at 12:21 PM, David Schinazi 
mailto:dschin...@apple.com>> wrote:
Hi Xuelei,

Can you elaborate on what proxy protocol you're using that can reuse the TCP 
connection for follow on connections, and what semantics it has?
As far as I know, SOCKS and HTTP CONNECT don't support this.
Additionally, the close_notify alerts are sent encrypted so the proxy wouldn't 
be able to tell that applications are done with TLS.

Thanks,
David



On Mar 7, 2018, at 11:24, Xuelei Fan 
mailto:xuelei@vimous.com>> wrote:

Hi David,

This issue happens when the TLS connection is established/layered on an 
existing TCP connection.  For example:
1. A client connects to a proxy
2. The client establishes a TLS 1.3 connection to a server via the proxy.
3. The  server delivers 2+ records  to the client.
4. The client receives the 1st record, and intends to close the TLS connection

As the  existing TCP connection may be used for follow on connections, it might 
not be a solution to close the TCP connection directly.  And the client would 
better cleanup the data delivered by the server.   Otherwise, the data may be 
used by the next follow on connection and may cause unknown issues.

Then the question comes to me: how does the client close the TLS connection? 
Closing the TCP connection may be not desired as it does not really have a TCP 
connection to the server.  It would be nice to close the TLS connection but 
keeping the TCP connection alive.

Looks like there is no way to close the read side of a TLS connection in TLS 
layer per the current TLS 1.3 specification.  The close_notify is used to 
indicate the closure of client write side, but not the server write side.  If 
the client sends the close_notify for read side closure, after receiving the 
close_notify the server side will not receive data, but may still send data.  
Even if the server side stop sending data, the client side does not actually 
know how may data has been delivered by the server, and how to clean up the TLS 
channel.

For such cases in TLS 1.2, the client can send a  close_notify alert and then 
wait for the server close_notify alert, and all of the intermediate data is 
discarded.  There are still some problems, but in theory the client can cleanup 
the TCP channel.

In the TLS 1.3 specification, it says:


   If the application protocol using TLS provides that any data may be

   carried over the underlying transport after the TLS connection is

   closed, the TLS implementation MUST receive a "close_notify" alert

   before indicating end-of-data to the application-layer.

For client read side in above case, it means that the server side MUST deliver 
a close_notify.  But it does not say if a client initiates the TLS closure, how 
could the client indicates the server for a close_notify alert.

Thanks for the suggestion of TCP RST option.  I will evaluate if TCP options 
can help.

Thanks & Regards,
Xuelei Fan


On Wed, Mar 7, 2018 at 10:19 AM, David Schinazi 
mailto:dschin...@apple.com>> wrote:
Hi Xuelei,

Do you have an example for when you would need to gracefully close the read 
side?
If you're downloading a 10GB video and the user cancels the download, you can 
simply tear down the TCP connection by sending a RST.
The benefit of having a graceful read close would be for the

Re: [TLS] Spencer Dawkins' No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Eric Rescorla]

On Wed, Mar 7, 2018 at 9:25 PM, Spencer Dawkins <
spencerdawkins.i...@gmail.com> wrote:

> Spencer Dawkins has entered the following ballot position for
> draft-ietf-tls-tls13-26: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
>
>
>
> --
> COMMENT:
> --
>
> Nice work. Of course, no one reads a 150-page document without wondering
> about
> a few things ...
>
> I suspect that
>
>Because
>TLS 1.3 changes the way keys are derived it updates [RFC5705] as
>described in Section 7.5 it also changes how OCSP messages are
>carried and therefore updates [RFC6066] and obsoletes [RFC6961] as
>described in section Section 4.4.2.1.
>
> is a run-on sentence. Perhaps a period after "section 7.5"?
>

Thanks, yes.



Is "forward secrecy" (the term used in this draft) the same thing as
> "perfect
> forward secrecy" (the term I hear most often, and it does appear in one
> reference title)?
>

Close enough. The basic problem is that people get hung up on "perfect".
So, consider the case where you generate a fresh DH key every hour or
so, but you reuse it for that period. It's clear you get forward secrecy
once that key s deleted but is that "perfect" because you have a window
of exposure uring that hour? So, we just decided to use "forward secret"

The use of "mandatory" as the name of a vector in
>
>   In the following example, mandatory is a vector that must contain
>between 300 and 400 bytes of type opaque.
>
> was pretty hard to parse until I read further. Did anyone else find that
> confusing?
>

I don't :)


In this text,
>
>   When multiple extensions of different types are present, the
>extensions MAY appear in any order, with the exception of
>"pre_shared_key" Section 4.2.11 which MUST be the last extension in
>the ClientHello.  There MUST NOT be more than one extension of the
>same type in a given extension block.
>
> I didn't see what to do if the MUST NOT is violated. Is that worth
> mentioning?
>

I don't think it's necessary. In general, you can always abort on a protocol
violation like this, but there's no known reason you would *need* to, other
than it would create interop problems if (say) A thinks extension #1 matters
and B thinks #2 matters, but of course there are lots of possible causes
of interop. This is different from cases where there are clear security
problems if you don't check some value or something.


> In this text,
>
>An
>implementation which receives any other change_cipher_spec value or
>which receives a protected change_cipher_spec record MUST abort the
>handshake with an "unexpected_message" alert.  A change_cipher_spec
>record received before the first ClientHello message or after the
>peer's Finished message MUST be treated as an unexpected record type.
>
>Implementations MUST NOT send record types not defined in this
>document unless negotiated by some extension.  If a TLS
>implementation receives an unexpected record type, it MUST terminate
>the connection with an "unexpected_message" alert.  New record
>content type values are assigned by IANA in the TLS Content Type
>Registry as described in Section 11.
>
> I wondered if there was a difference between an unexpected record type and
> and
> unexpected message.
>

Ah, good. One alert for two conditions:

1. An unexpected record type at the record layer.
2. An unexpected handshake message.


I wondered why
>
>Newer
>clients or servers, when communicating with newer peers, SHOULD
>negotiate the most preferred common parameters.
>
> was not a MUST.
>

Ugh, this is actually not even a normative statement, It's just a statement
of
what the protocol is supposed to do. Good catch!

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

Re: [TLS] Spencer Dawkins' No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Sean Turner]

> On Mar 8, 2018, at 08:10, Eric Rescorla  wrote:
> 
> 
> 
> On Wed, Mar 7, 2018 at 9:25 PM, Spencer Dawkins 
>  wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-tls-tls13-26: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Nice work. Of course, no one reads a 150-page document without wondering about
> a few things ...
> 
> I suspect that
> 
>Because
>TLS 1.3 changes the way keys are derived it updates [RFC5705] as
>described in Section 7.5 it also changes how OCSP messages are
>carried and therefore updates [RFC6066] and obsoletes [RFC6961] as
>described in section Section 4.4.2.1.
> 
> is a run-on sentence. Perhaps a period after "section 7.5"?
> 
> Thanks, yes.

Fix in https://github.com/tlswg/tls13-spec/pull/1169

> Is "forward secrecy" (the term used in this draft) the same thing as "perfect
> forward secrecy" (the term I hear most often, and it does appear in one
> reference title)?
> 
> Close enough. The basic problem is that people get hung up on "perfect".
> So, consider the case where you generate a fresh DH key every hour or
> so, but you reuse it for that period. It's clear you get forward secrecy
> once that key s deleted but is that "perfect" because you have a window
> of exposure uring that hour? So, we just decided to use "forward secret"
> 
> The use of "mandatory" as the name of a vector in
> 
>   In the following example, mandatory is a vector that must contain
>between 300 and 400 bytes of type opaque.
> 
> was pretty hard to parse until I read further. Did anyone else find that
> confusing?
> 
> I don't :)

It’s at least on the same page so it’s not too hard to scan lower.  If we 
called it hooziewazit it’ll still be after it ;)

> In this text,
> 
>   When multiple extensions of different types are present, the
>extensions MAY appear in any order, with the exception of
>"pre_shared_key" Section 4.2.11 which MUST be the last extension in
>the ClientHello.  There MUST NOT be more than one extension of the
>same type in a given extension block.
> 
> I didn't see what to do if the MUST NOT is violated. Is that worth mentioning?
> 
> I don't think it's necessary. In general, you can always abort on a protocol
> violation like this, but there's no known reason you would *need* to, other
> than it would create interop problems if (say) A thinks extension #1 matters
> and B thinks #2 matters, but of course there are lots of possible causes
> of interop. This is different from cases where there are clear security
> problems if you don't check some value or something.
> 
> 
> In this text,
> 
>An
>implementation which receives any other change_cipher_spec value or
>which receives a protected change_cipher_spec record MUST abort the
>handshake with an "unexpected_message" alert.  A change_cipher_spec
>record received before the first ClientHello message or after the
>peer's Finished message MUST be treated as an unexpected record type.
> 
>Implementations MUST NOT send record types not defined in this
>document unless negotiated by some extension.  If a TLS
>implementation receives an unexpected record type, it MUST terminate
>the connection with an "unexpected_message" alert.  New record
>content type values are assigned by IANA in the TLS Content Type
>Registry as described in Section 11.
> 
> I wondered if there was a difference between an unexpected record type and and
> unexpected message.
> 
> Ah, good. One alert for two conditions:
> 
> 1. An unexpected record type at the record layer.
> 2. An unexpected handshake message.
> 
> 
> I wondered why
> 
>Newer
>clients or servers, when communicating with newer peers, SHOULD
>negotiate the most preferred common parameters.
> 
> was not a MUST.
> 
> Ugh, this is actually not even a normative statement, It's just a statement of
> what the protocol is supposed to do. Good catch!

I made it a MUST in:
https://github.com/tlswg/tls13-spec/pull/1172

spt

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

[TLS] TLS@IETF101 Agenda Posted

[Sean Turner]

I’ve posted the draft agendas:

Monday:
  https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessb

Wednesday:
  https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessa

spt


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

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

Hi Sean, Joe,

On 08/03/18 16:20, Sean Turner wrote:
> I’ve posted the draft agendas:
> 
> Monday:
>   https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessb

That includes:
"
TLS Vizability - Russ & Chairs - 30min
 - 10min draft - Russ
  https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/
 - 10min discussion - Chairs
 - 10min wrap-up - Chairs
"

Consider this as an objection to that agenda item
being given any time. I also have some questions
below.

This topic was discussed at length in Prague with a
very clear lack of consensus to consider any work in
that space, despite there being quite a few fans of
doing such work in the room that day. I don't see
that anything has changed in the meantime.

Russ' draft was discussed on the list last year, also
with (ISTM) no consensus at all to do any work in
that space. (While you didn't make a consensus call,
am I wrong?) The -01 version is not significantly
different from what was discussed on the list so I
see no need for any presentation nor discussion time.

Given the above, on what basis are meeting attendees
being asked to waste yet more f2f time on this topic?

And why is another want-it/hate-it exercise useful?

As chairs, are you going to continually allow the same
topic to be raised, in the face of a very clear lack
of consensus to do anything in this space? If not,
then what's the plan for ending this?

Thanks,
S.

PS: I also strongly object to the "visibility" euphemism,
and while that's partly a comment on the draft, it would
also IMO be a significant error to pose any questions to
the WG based on that euphemism.



0x7B172BEA.asc
Description: application/pgp-keys


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

Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3

[Tony Putman]

Hi Ekr,

Firstly, thanks for this. My primary reason for putting together draft-putman 
was to propose a handshake exchange which only uses a single asymmetric 
algorithm. If this proposal is extended to include raw public keys (I think 
these are already supported, but not mentioned in the text) and an ECDH-based 
MAC for client authentication, then this satisfies my constraints.

As a single data point, I can state that some of the IoT products that I'm 
working with already use static ECDH keys for client authentication (though not 
within TLS).

Although OPTLS is able to use 0-RTT, I don't see how this capability could be 
used in this implementation, even if the client knows the server static key. 
Because SS is only included in the key schedule when the master secret is 
generated, the client_early_traffic_secret has no input secret. Conversely, if 
the SS is included in the key schedule as the PSK, then the certificate cannot 
be decrypted by a client which does not have the server static key.

My conclusion is that, although this is usable with pre-provisioned ECDH keys, 
this is not the main use case. The different use case results in fewer 
properties; in particular (as noted), a client static key is not included in 
the key schedule. This means application data sent from the server before the 
client finished message is received is sent to an unauthenticated client (this 
is not the case with either PSK auth or with draft-putman).

I think that this and draft-putman are not competing, but rather that they 
serve different use cases. They could be synergistic, such that this draft 
provides a mechanism for distributing a static key which could later be used in 
a draft-putman exchange; however, the natural continuation would be to use a 
resumption PSK, so this would only be useful if there were a long gap between 
session, which seems unlikely.

Regards,
Tony

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Christopher Wood
Sent: 07 March 2018 01:26
To: ; Eric Rescorla
Subject: Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3

Thanks for putting this together! I’m in favor of the mechanism and look 
forward to discussing it. Negotiating with signature_algorithms is a simple way 
to roll this out, it fits in cleanly with the key schedule, and the benefits 
outlined in the introduction (PRNG hardening, plausible deniability, etc.) seem 
worth the effort. Although the approach has its roots in OPTLS, we will 
certainly need to re-assess its impact on the handshake. (I know of some folks 
actively working on this.) We also need to spend more time thinking about the 
open issues — specifically, the story around early data encryption. This 
variant has the benefit of enabling early data with public key encryption, as 
opposed to (trackable) symmetric key encryption. It’s unclear to me whether or 
not we need to address the static share publication issue for this benefit.

Anyway, thanks again for the draft. I’ll read it carefully before London.

Best,
Chris

On Mar 5, 2018, 4:14 PM -0500, Eric Rescorla 
mailto:e...@rtfm.com>>, wrote:

Hi folks,

Here's another entry in the DH-only pile.

I've just posted:
   draft-rescorla-tls13-semistatic-dh-00

This implements a semi-static DH exchange mostly borrowed from
OPTLS [0]. There are obviously connections with draft-putman, but
this is more oriented towards implementing a 1-RTT style
exchange where the client has no foreknowledge of the server's
capabilities (though it's extensible to 0-RTT) than towards
pre-distributed DH keys, and has less invasive changes to the
key schedule.

We'd like 10 minutes to discuss this in London.

Thanks,
-Ekr

[0] http://ieeexplore.ieee.org/abstract/document/7467348/



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

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, 
SN16 0RP, UK.
This message is intended solely for the addressee and may contain confidential 
information. If you have received this message in error, please immediately and 
permanently delete it, and do not use, copy or disclose the information 
contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & training.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3, how to close the read side of a connection?

[David Schinazi]

Hi Tony,

I agree with you, TLS should not have requirements on the underlying transport.
If there is a use case that would require endpoints have a way to signal to the 
peer that they're done reading, I would suggest writing a draft about a new 
close_request alert.
I personally don't think this needs to be in the main TLS 1.3 spec, though.

Thanks,
David


> On Mar 8, 2018, at 02:23, Tony Putman  wrote:
> 
> David,
>  
> I think this is a valid concern. It's been commented on 
> (https://www.ietf.org/mail-archive/web/tls/current/msg25579.html 
> ) that the 
> draft has NO requirements on the underlying transport. There are potentially 
> other transports for TLS (such as being worked by the ATLAS WG) which may not 
> have a way to terminate the transport.
>  
> At a minimum this must be addressed in DTLS, but it seems to me that the 
> addition of a close_request alert is a small matter which would benefit both 
> protocols. Of course, this could be added at a later date if/when the need 
> arises.
>  
> Regards,
> Tony
>  
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Xuelei Fan
> Sent: 07 March 2018 20:54
> To: David Schinazi
> Cc: tls@ietf.org
> Subject: Re: [TLS] TLS 1.3, how to close the read side of a connection?
>  
> Hi David,
>  
> The case I can think of now is the START TLS protocols (Opportunistic TLS).  
> But looks like these protocols need to use an existing plain-text socket, and 
> then establish a TLS connection over it, and will never go back to plain-text 
> again.  Maybe, for START TLS protocols, closing TLS connection just implies 
> close the underlying TCP socket in practice.  We don't do that previously as 
> we don't know how the  plain-text socket can be used in practice in the 
> follow on processes after TLS get closed (while socket still alive).   If an 
> application gets indication that the TLS connection get closed, it can use 
> the cleanup socket.  So it does not actually need to understand the TLS 
> specifics.
>  
> I'm a little bit hesitate if there is a reality user case for such 
> requirement.  Maybe, I can just close the socket, and see what the 
> compatibility impact could be.
>  
> Thanks,
> Xuelei
>  
> On Wed, Mar 7, 2018 at 12:21 PM, David Schinazi  > wrote:
> Hi Xuelei,
>  
> Can you elaborate on what proxy protocol you're using that can reuse the TCP 
> connection for follow on connections, and what semantics it has?
> As far as I know, SOCKS and HTTP CONNECT don't support this.
> Additionally, the close_notify alerts are sent encrypted so the proxy 
> wouldn't be able to tell that applications are done with TLS.
>  
> Thanks,
> David
>  
> 
> 
> On Mar 7, 2018, at 11:24, Xuelei Fan  > wrote:
>  
> Hi David,
>  
> This issue happens when the TLS connection is established/layered on an 
> existing TCP connection.  For example:
> 1. A client connects to a proxy
> 2. The client establishes a TLS 1.3 connection to a server via the proxy.
> 3. The  server delivers 2+ records  to the client.
> 4. The client receives the 1st record, and intends to close the TLS connection
>  
> As the  existing TCP connection may be used for follow on connections, it 
> might not be a solution to close the TCP connection directly.  And the client 
> would better cleanup the data delivered by the server.   Otherwise, the data 
> may be used by the next follow on connection and may cause unknown issues.
>  
> Then the question comes to me: how does the client close the TLS connection? 
> Closing the TCP connection may be not desired as it does not really have a 
> TCP connection to the server.  It would be nice to close the TLS connection 
> but keeping the TCP connection alive.
>  
> Looks like there is no way to close the read side of a TLS connection in TLS 
> layer per the current TLS 1.3 specification.  The close_notify is used to 
> indicate the closure of client write side, but not the server write side.  If 
> the client sends the close_notify for read side closure, after receiving the 
> close_notify the server side will not receive data, but may still send data.  
> Even if the server side stop sending data, the client side does not actually 
> know how may data has been delivered by the server, and how to clean up the 
> TLS channel.
>  
> For such cases in TLS 1.2, the client can send a  close_notify alert and then 
> wait for the server close_notify alert, and all of the intermediate data is 
> discarded.  There are still some problems, but in theory the client can 
> cleanup the TCP channel.
>  
> In the TLS 1.3 specification, it says:
>
>If the application protocol using TLS provides that any data may be
>carried over the underlying transport after the TLS connection is
>closed, the TLS implementation MUST receive a "close_notify" alert
>before indicating end-of-data to the application-layer.
>  
> For client read s

Re: [TLS] TLS 1.3, how to close the read side of a connection?

[Salz, Rich]

Sure, the requirements are: don’t close the transport until TLS says it is 
done. You can’t do half-duplex close with TLS.

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

Re: [TLS] TLS 1.3, how to close the read side of a connection?

[Tony Putman]

Fully agree. Defer it until there is a need.
-- Tony

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David Schinazi
Sent: 08 March 2018 17:48
To: Tony Putman
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3, how to close the read side of a connection?

Hi Tony,

I agree with you, TLS should not have requirements on the underlying transport.
If there is a use case that would require endpoints have a way to signal to the 
peer that they're done reading, I would suggest writing a draft about a new 
close_request alert.
I personally don't think this needs to be in the main TLS 1.3 spec, though.

Thanks,
David



On Mar 8, 2018, at 02:23, Tony Putman 
mailto:tony.put...@dyson.com>> wrote:

David,

I think this is a valid concern. It's been commented on 
(https://www.ietf.org/mail-archive/web/tls/current/msg25579.html) that the 
draft has NO requirements on the underlying transport. There are potentially 
other transports for TLS (such as being worked by the ATLAS WG) which may not 
have a way to terminate the transport.

At a minimum this must be addressed in DTLS, but it seems to me that the 
addition of a close_request alert is a small matter which would benefit both 
protocols. Of course, this could be added at a later date if/when the need 
arises.

Regards,
Tony

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Xuelei Fan
Sent: 07 March 2018 20:54
To: David Schinazi
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3, how to close the read side of a connection?

Hi David,

The case I can think of now is the START TLS protocols (Opportunistic TLS).  
But looks like these protocols need to use an existing plain-text socket, and 
then establish a TLS connection over it, and will never go back to plain-text 
again.  Maybe, for START TLS protocols, closing TLS connection just implies 
close the underlying TCP socket in practice.  We don't do that previously as we 
don't know how the  plain-text socket can be used in practice in the follow on 
processes after TLS get closed (while socket still alive).   If an application 
gets indication that the TLS connection get closed, it can use the cleanup 
socket.  So it does not actually need to understand the TLS specifics.

I'm a little bit hesitate if there is a reality user case for such requirement. 
 Maybe, I can just close the socket, and see what the compatibility impact 
could be.

Thanks,
Xuelei

On Wed, Mar 7, 2018 at 12:21 PM, David Schinazi 
mailto:dschin...@apple.com>> wrote:
Hi Xuelei,

Can you elaborate on what proxy protocol you're using that can reuse the TCP 
connection for follow on connections, and what semantics it has?
As far as I know, SOCKS and HTTP CONNECT don't support this.
Additionally, the close_notify alerts are sent encrypted so the proxy wouldn't 
be able to tell that applications are done with TLS.

Thanks,
David




On Mar 7, 2018, at 11:24, Xuelei Fan 
mailto:xuelei@vimous.com>> wrote:

Hi David,

This issue happens when the TLS connection is established/layered on an 
existing TCP connection.  For example:
1. A client connects to a proxy
2. The client establishes a TLS 1.3 connection to a server via the proxy.
3. The  server delivers 2+ records  to the client.
4. The client receives the 1st record, and intends to close the TLS connection

As the  existing TCP connection may be used for follow on connections, it might 
not be a solution to close the TCP connection directly.  And the client would 
better cleanup the data delivered by the server.   Otherwise, the data may be 
used by the next follow on connection and may cause unknown issues.

Then the question comes to me: how does the client close the TLS connection? 
Closing the TCP connection may be not desired as it does not really have a TCP 
connection to the server.  It would be nice to close the TLS connection but 
keeping the TCP connection alive.

Looks like there is no way to close the read side of a TLS connection in TLS 
layer per the current TLS 1.3 specification.  The close_notify is used to 
indicate the closure of client write side, but not the server write side.  If 
the client sends the close_notify for read side closure, after receiving the 
close_notify the server side will not receive data, but may still send data.  
Even if the server side stop sending data, the client side does not actually 
know how may data has been delivered by the server, and how to clean up the TLS 
channel.

For such cases in TLS 1.2, the client can send a  close_notify alert and then 
wait for the server close_notify alert, and all of the intermediate data is 
discarded.  There are still some problems, but in theory the client can cleanup 
the TCP channel.

In the TLS 1.3 specification, it says:


   If the application protocol using TLS provides that any data may be

   carried over the underlying transport after the TLS connection is

   closed, the TLS implementation MUST receive a "close_notify" alert

   before indicating end-of-data to the application-layer.

Fo

Re: [TLS] TLS 1.3, how to close the read side of a connection?

[Christopher Wood]

+1

On Mar 8, 2018, 12:56 PM -0500, Tony Putman , wrote:
> Fully agree. Defer it until there is a need.
> -- Tony
>
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David Schinazi
> Sent: 08 March 2018 17:48
> To: Tony Putman
> Cc: tls@ietf.org
> Subject: Re: [TLS] TLS 1.3, how to close the read side of a connection?
>
> Hi Tony,
>
> I agree with you, TLS should not have requirements on the underlying 
> transport.
> If there is a use case that would require endpoints have a way to signal to 
> the peer that they're done reading, I would suggest writing a draft about a 
> new close_request alert.
> I personally don't think this needs to be in the main TLS 1.3 spec, though.
>
> Thanks,
> David
>
>
>
> On Mar 8, 2018, at 02:23, Tony Putman  wrote:
>
> David,
>
> I think this is a valid concern. It's been commented on 
> (https://www.ietf.org/mail-archive/web/tls/current/msg25579.html) that the 
> draft has NO requirements on the underlying transport. There are potentially 
> other transports for TLS (such as being worked by the ATLAS WG) which may not 
> have a way to terminate the transport.
>
> At a minimum this must be addressed in DTLS, but it seems to me that the 
> addition of a close_request alert is a small matter which would benefit both 
> protocols. Of course, this could be added at a later date if/when the need 
> arises.
>
> Regards,
> Tony
>
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Xuelei Fan
> Sent: 07 March 2018 20:54
> To: David Schinazi
> Cc: tls@ietf.org
> Subject: Re: [TLS] TLS 1.3, how to close the read side of a connection?
>
> Hi David,
>
> The case I can think of now is the START TLS protocols (Opportunistic TLS).  
> But looks like these protocols need to use an existing plain-text socket, and 
> then establish a TLS connection over it, and will never go back to plain-text 
> again.  Maybe, for START TLS protocols, closing TLS connection just implies 
> close the underlying TCP socket in practice.  We don't do that previously as 
> we don't know how the  plain-text socket can be used in practice in the 
> follow on processes after TLS get closed (while socket still alive).   If an 
> application gets indication that the TLS connection get closed, it can use 
> the cleanup socket.  So it does not actually need to understand the TLS 
> specifics.
>
> I'm a little bit hesitate if there is a reality user case for such 
> requirement.  Maybe, I can just close the socket, and see what the 
> compatibility impact could be.
>
> Thanks,
> Xuelei
>
> On Wed, Mar 7, 2018 at 12:21 PM, David Schinazi  wrote:
> Hi Xuelei,
>
> Can you elaborate on what proxy protocol you're using that can reuse the TCP 
> connection for follow on connections, and what semantics it has?
> As far as I know, SOCKS and HTTP CONNECT don't support this.
> Additionally, the close_notify alerts are sent encrypted so the proxy 
> wouldn't be able to tell that applications are done with TLS.
>
> Thanks,
> David
>
>
>
>
> On Mar 7, 2018, at 11:24, Xuelei Fan  wrote:
>
> Hi David,
>
> This issue happens when the TLS connection is established/layered on an 
> existing TCP connection.  For example:
> 1. A client connects to a proxy
> 2. The client establishes a TLS 1.3 connection to a server via the proxy.
> 3. The  server delivers 2+ records  to the client.
> 4. The client receives the 1st record, and intends to close the TLS connection
>
> As the  existing TCP connection may be used for follow on connections, it 
> might not be a solution to close the TCP connection directly.  And the client 
> would better cleanup the data delivered by the server.   Otherwise, the data 
> may be used by the next follow on connection and may cause unknown issues.
>
> Then the question comes to me: how does the client close the TLS connection? 
> Closing the TCP connection may be not desired as it does not really have a 
> TCP connection to the server.  It would be nice to close the TLS connection 
> but keeping the TCP connection alive.
>
> Looks like there is no way to close the read side of a TLS connection in TLS 
> layer per the current TLS 1.3 specification.  The close_notify is used to 
> indicate the closure of client write side, but not the server write side.  If 
> the client sends the close_notify for read side closure, after receiving the 
> close_notify the server side will not receive data, but may still send data.  
> Even if the server side stop sending data, the client side does not actually 
> know how may data has been delivered by the server, and how to clean up the 
> TLS channel.
>
> For such cases in TLS 1.2, the client can send a  close_notify alert and then 
> wait for the server close_notify alert, and all of the intermediate data is 
> discarded.  There are still some problems, but in theory the client can 
> cleanup the TCP channel.
>
> In the TLS 1.3 specification, it says:
>
>   If the application protocol using TLS provides that any data may be
>   carried over the underlying transport after th

Re: [TLS] TLS@IETF101 Agenda Posted

[Artyom Gavrichenkov]

Hi Sean, Joe,

WG also has this at its disposal:
https://tools.ietf.org/html/draft-fenter-tls-decryption-00
Will that be discussed along with draft-rhrd-tls-tls13-visibility?
Those two seem to be rather connected/dependant on each other.

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: xima...@gmail.com
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58


On Thu, Mar 8, 2018 at 12:21 PM, Stephen Farrell
 wrote:
>
> Hi Sean, Joe,
>
> On 08/03/18 16:20, Sean Turner wrote:
>> I’ve posted the draft agendas:
>>
>> Monday:
>>   https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessb
>
> That includes:
> "
> TLS Vizability - Russ & Chairs - 30min
>  - 10min draft - Russ
>   https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/
>  - 10min discussion - Chairs
>  - 10min wrap-up - Chairs
> "
>
> Consider this as an objection to that agenda item
> being given any time. I also have some questions
> below.
>
> This topic was discussed at length in Prague with a
> very clear lack of consensus to consider any work in
> that space, despite there being quite a few fans of
> doing such work in the room that day. I don't see
> that anything has changed in the meantime.
>
> Russ' draft was discussed on the list last year, also
> with (ISTM) no consensus at all to do any work in
> that space. (While you didn't make a consensus call,
> am I wrong?) The -01 version is not significantly
> different from what was discussed on the list so I
> see no need for any presentation nor discussion time.
>
> Given the above, on what basis are meeting attendees
> being asked to waste yet more f2f time on this topic?
>
> And why is another want-it/hate-it exercise useful?
>
> As chairs, are you going to continually allow the same
> topic to be raised, in the face of a very clear lack
> of consensus to do anything in this space? If not,
> then what's the plan for ending this?
>
> Thanks,
> S.
>
> PS: I also strongly object to the "visibility" euphemism,
> and while that's partly a comment on the draft, it would
> also IMO be a significant error to pose any questions to
> the WG based on that euphemism.
>
>
> ___
> 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] TLS@IETF101 Agenda Posted

[Joseph Salowey]

Hi Stephen,

In the meeting in Prague there was interest in this problem space, but
neither the consensus to accept or reject this work.  The authors have
revised their proposal to address some of the concerns raised by working
group members and are asking to bring the new approach in front of the
working group.  I believe in this case this is the right thing to do even
if it appears there is some repetition of topic.   However, if the new
approach fails to achieve significantly more support I believe the authors
will need to find another path for their work that does not go through the
TLS working group.

Cheers,

Joe

On Thu, Mar 8, 2018 at 9:21 AM, Stephen Farrell 
wrote:

>
> Hi Sean, Joe,
>
> On 08/03/18 16:20, Sean Turner wrote:
> > I’ve posted the draft agendas:
> >
> > Monday:
> >   https://datatracker.ietf.org/meeting/101/materials/agenda-
> 101-tls-sessb
>
> That includes:
> "
> TLS Vizability - Russ & Chairs - 30min
>  - 10min draft - Russ
>   https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/
>  - 10min discussion - Chairs
>  - 10min wrap-up - Chairs
> "
>
> Consider this as an objection to that agenda item
> being given any time. I also have some questions
> below.
>
> This topic was discussed at length in Prague with a
> very clear lack of consensus to consider any work in
> that space, despite there being quite a few fans of
> doing such work in the room that day. I don't see
> that anything has changed in the meantime.
>
> Russ' draft was discussed on the list last year, also
> with (ISTM) no consensus at all to do any work in
> that space. (While you didn't make a consensus call,
> am I wrong?) The -01 version is not significantly
> different from what was discussed on the list so I
> see no need for any presentation nor discussion time.
>
> Given the above, on what basis are meeting attendees
> being asked to waste yet more f2f time on this topic?
>
> And why is another want-it/hate-it exercise useful?
>
> As chairs, are you going to continually allow the same
> topic to be raised, in the face of a very clear lack
> of consensus to do anything in this space? If not,
> then what's the plan for ending this?
>
> Thanks,
> S.
>
> PS: I also strongly object to the "visibility" euphemism,
> and while that's partly a comment on the draft, it would
> also IMO be a significant error to pose any questions to
> the WG based on that euphemism.
>
>
> ___
> 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] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3

[Eric Rescorla]

On Thu, Mar 8, 2018 at 9:41 AM, Tony Putman  wrote:

> Hi Ekr,
>
>
>
> Firstly, thanks for this. My primary reason for putting together
> draft-putman was to propose a handshake exchange which only uses a single
> asymmetric algorithm. If this proposal is extended to include raw public
> keys (I think these are already supported, but not mentioned in the text)
> and an ECDH-based MAC for client authentication, then this satisfies my
> constraints.
>

Yep, that should actually work just fine.


As a single data point, I can state that some of the IoT products that I'm
> working with already use static ECDH keys for client authentication (though
> not within TLS).
>



>
>
> Although OPTLS is able to use 0-RTT, I don't see how this capability could
> be used in this implementation, even if the client knows the server static
> key. Because SS is only included in the key schedule when the master secret
> is generated, the client_early_traffic_secret has no input secret.
> Conversely, if the SS is included in the key schedule as the PSK, then the
> certificate cannot be decrypted by a client which does not have the server
> static key.
>

Yes, I agree with you. OPTLS had a less linear key schedule. I think if you
wanted to do 0-RTT you would have to have it be a pretend PSK as you
suggest in your draft.


I think that this and draft-putman are not competing, but rather that they
> serve different use case
>

Agreed. It sounds like you have a set of use cases where you know how to
predistribute the server key? This is the part we found challenging int he
web context.

-Ekr





> s. They could be synergistic, such that this draft provides a mechanism
> for distributing a static key which could later be used in a draft-putman
> exchange; however, the natural continuation would be to use a resumption
> PSK, so this would only be useful if there were a long gap between session,
> which seems unlikely.
>
>
>
> Regards,
>
> Tony
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Christopher Wood
> *Sent:* 07 March 2018 01:26
> *To:* ; Eric Rescorla
> *Subject:* Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS
> 1.3
>
>
>
> Thanks for putting this together! I’m in favor of the mechanism and look
> forward to discussing it. Negotiating with signature_algorithms is a simple
> way to roll this out, it fits in cleanly with the key schedule, and the
> benefits outlined in the introduction (PRNG hardening, plausible
> deniability, etc.) seem worth the effort. Although the approach has its
> roots in OPTLS, we will certainly need to re-assess its impact on the
> handshake. (I know of some folks actively working on this.) We also need to
> spend more time thinking about the open issues — specifically, the story
> around early data encryption. This variant has the benefit of enabling
> early data with public key encryption, as opposed to (trackable) symmetric
> key encryption. It’s unclear to me whether or not we need to address the
> static share publication issue for this benefit.
>
>
>
> Anyway, thanks again for the draft. I’ll read it carefully before London.
>
>
> Best,
>
> Chris
>
>
> On Mar 5, 2018, 4:14 PM -0500, Eric Rescorla , wrote:
>
> Hi folks,
>
>
>
> Here's another entry in the DH-only pile.
>
>
>
> I've just posted:
>
>draft-rescorla-tls13-semistatic-dh-00
>
>
>
> This implements a semi-static DH exchange mostly borrowed from
>
> OPTLS [0]. There are obviously connections with draft-putman, but
>
> this is more oriented towards implementing a 1-RTT style
>
> exchange where the client has no foreknowledge of the server's
>
> capabilities (though it's extensible to 0-RTT) than towards
>
> pre-distributed DH keys, and has less invasive changes to the
>
> key schedule.
>
>
>
> We'd like 10 minutes to discuss this in London.
>
>
>
> Thanks,
>
> -Ekr
>
>
>
> [0] http://ieeexplore.ieee.org/abstract/document/7467348/
>
>
>
>
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> Dyson Technology Limited, company number 01959090, Tetbury Hill,
> Malmesbury, SN16 0RP, UK.
> This message is intended solely for the addressee and may contain
> confidential information. If you have received this message in error,
> please immediately and permanently delete it, and do not use, copy or
> disclose the information contained in this message or in any attachment.
> Dyson may monitor email traffic data and content for security & training.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Spencer Dawkins' No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Martin Thomson]

On Fri, Mar 9, 2018 at 12:10 AM, Eric Rescorla  wrote:
>> I wondered why
>>
>>Newer
>>clients or servers, when communicating with newer peers, SHOULD
>>negotiate the most preferred common parameters.
>>
>> was not a MUST.
>
>
> Ugh, this is actually not even a normative statement, It's just a statement
> of
> what the protocol is supposed to do. Good catch!

Drop the SHOULD, yeah.  Is it worth noting that it's the server's
preference that wins?  As in:

   Newer clients or servers, when communicating with newer peers,
negotiate the common parameters most preferred by the server.

Or is that too constraining?

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

Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3

[Christopher Wood]

On Mar 8, 2018, 6:25 PM -0500, Eric Rescorla , wrote:
> > On Thu, Mar 8, 2018 at 9:41 AM, Tony Putman  wrote:
> > > Hi Ekr,
> > >
> > > Firstly, thanks for this. My primary reason for putting together 
> > > draft-putman was to propose a handshake exchange which only uses a single 
> > > asymmetric algorithm. If this proposal is extended to include raw public 
> > > keys (I think these are already supported, but not mentioned in the text) 
> > > and an ECDH-based MAC for client authentication, then this satisfies my 
> > > constraints.
> >
> > Yep, that should actually work just fine.

Agreed.

> >
> >
> > > As a single data point, I can state that some of the IoT products that 
> > > I'm working with already use static ECDH keys for client authentication 
> > > (though not within TLS).
> >
> >
> > >
> > > Although OPTLS is able to use 0-RTT, I don't see how this capability 
> > > could be used in this implementation, even if the client knows the server 
> > > static key. Because SS is only included in the key schedule when the 
> > > master secret is generated, the client_early_traffic_secret has no input 
> > > secret. Conversely, if the SS is included in the key schedule as the PSK, 
> > > then the certificate cannot be decrypted by a client which does not have 
> > > the server static key.
> >
> > Yes, I agree with you. OPTLS had a less linear key schedule. I think if you 
> > wanted to do 0-RTT you would have to have it be a pretend PSK as you 
> > suggest in your draft.

That sounds right — the early application data key with OPTLS is `g^{sx}` 
instead of `psk`.

Best,
Chris

> >
> >
> > > I think that this and draft-putman are not competing, but rather that 
> > > they serve different use case
> >
> > Agreed. It sounds like you have a set of use cases where you know how to 
> > predistribute the server key? This is the part we found challenging int he 
> > web context.
> >
> > -Ekr
> >
> >
> >
> >
> > > s. They could be synergistic, such that this draft provides a mechanism 
> > > for distributing a static key which could later be used in a draft-putman 
> > > exchange; however, the natural continuation would be to use a resumption 
> > > PSK, so this would only be useful if there were a long gap between 
> > > session, which seems unlikely.
> > >
> > > Regards,
> > > Tony
> > >
> > > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Christopher Wood
> > > Sent: 07 March 2018 01:26
> > > To: ; Eric Rescorla
> > > Subject: Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 
> > > 1.3
> > >
> > > Thanks for putting this together! I’m in favor of the mechanism and look 
> > > forward to discussing it. Negotiating with signature_algorithms is a 
> > > simple way to roll this out, it fits in cleanly with the key schedule, 
> > > and the benefits outlined in the introduction (PRNG hardening, plausible 
> > > deniability, etc.) seem worth the effort. Although the approach has its 
> > > roots in OPTLS, we will certainly need to re-assess its impact on the 
> > > handshake. (I know of some folks actively working on this.) We also need 
> > > to spend more time thinking about the open issues — specifically, the 
> > > story around early data encryption. This variant has the benefit of 
> > > enabling early data with public key encryption, as opposed to (trackable) 
> > > symmetric key encryption. It’s unclear to me whether or not we need to 
> > > address the static share publication issue for this benefit.
> > >
> > > Anyway, thanks again for the draft. I’ll read it carefully before London.
> > >
> > > Best,
> > > Chris
> > >
> > > On Mar 5, 2018, 4:14 PM -0500, Eric Rescorla , wrote:
> > >
> > > Hi folks,
> > >
> > > Here's another entry in the DH-only pile.
> > >
> > > I've just posted:
> > >    draft-rescorla-tls13-semistatic-dh-00
> > >
> > > This implements a semi-static DH exchange mostly borrowed from
> > > OPTLS [0]. There are obviously connections with draft-putman, but
> > > this is more oriented towards implementing a 1-RTT style
> > > exchange where the client has no foreknowledge of the server's
> > > capabilities (though it's extensible to 0-RTT) than towards
> > > pre-distributed DH keys, and has less invasive changes to the
> > > key schedule.
> > >
> > > We'd like 10 minutes to discuss this in London.
> > >
> > > Thanks,
> > > -Ekr
> > >
> > > [0] http://ieeexplore.ieee.org/abstract/document/7467348/
> > >
> > >
> > >
> > > ___
> > > TLS mailing list
> > > TLS@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tls
> > >
> > > Dyson Technology Limited, company number 01959090, Tetbury Hill, 
> > > Malmesbury, SN16 0RP, UK.
> > > This message is intended solely for the addressee and may contain 
> > > confidential information. If you have received this message in error, 
> > > please immediately and permanently delete it, and do not use, copy or 
> > > disclose the information contained in this message or in any attachment.
> > > D

Re: [TLS] TLS@IETF101 Agenda Posted

[Darin Pettis]

Artyom,
Thanks for mentioning the ID and you are right that draft Fenter is the
supporting problem description.

The reason it was written was to help folks understand why legitimate
internal out-of-band decryption is still needed on data once it reaches its
destination and that there isn’t a viable alternative that we are aware of.
   Especially not in-line MitM decryption.  It just doesn’t scale.  The
draft lists the legitimate internal requirements and speaks to the facts
around some of the suggestions that have been offered.

 It’s a good read and we are happy to answer questions in advance as
needed.

Darin

On Thu, Mar 8, 2018 at 4:11 PM Artyom Gavrichenkov 
wrote:

> Hi Sean, Joe,
>
> WG also has this at its disposal:
> https://tools.ietf.org/html/draft-fenter-tls-decryption-00
> Will that be discussed along with draft-rhrd-tls-tls13-visibility?
> Those two seem to be rather connected/dependant on each other.
>
> | Artyom Gavrichenkov
> | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
> | mailto: xima...@gmail.com
> | fb: ximaera
> | telegram: xima_era
> | skype: xima_era
> | tel. no: +7 916 515 49 58
>
>
> On Thu, Mar 8, 2018 at 12:21 PM, Stephen Farrell
>  wrote:
> >
> > Hi Sean, Joe,
> >
> > On 08/03/18 16:20, Sean Turner wrote:
> >> I’ve posted the draft agendas:
> >>
> >> Monday:
> >>
> https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessb
> >
> > That includes:
> > "
> > TLS Vizability - Russ & Chairs - 30min
> >  - 10min draft - Russ
> >   https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/
> >  - 10min discussion - Chairs
> >  - 10min wrap-up - Chairs
> > "
> >
> > Consider this as an objection to that agenda item
> > being given any time. I also have some questions
> > below.
> >
> > This topic was discussed at length in Prague with a
> > very clear lack of consensus to consider any work in
> > that space, despite there being quite a few fans of
> > doing such work in the room that day. I don't see
> > that anything has changed in the meantime.
> >
> > Russ' draft was discussed on the list last year, also
> > with (ISTM) no consensus at all to do any work in
> > that space. (While you didn't make a consensus call,
> > am I wrong?) The -01 version is not significantly
> > different from what was discussed on the list so I
> > see no need for any presentation nor discussion time.
> >
> > Given the above, on what basis are meeting attendees
> > being asked to waste yet more f2f time on this topic?
> >
> > And why is another want-it/hate-it exercise useful?
> >
> > As chairs, are you going to continually allow the same
> > topic to be raised, in the face of a very clear lack
> > of consensus to do anything in this space? If not,
> > then what's the plan for ending this?
> >
> > Thanks,
> > S.
> >
> > PS: I also strongly object to the "visibility" euphemism,
> > and while that's partly a comment on the draft, it would
> > also IMO be a significant error to pose any questions to
> > the WG based on that euphemism.
> >
> >
> > ___
> > 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[Artyom Gavrichenkov]

Hi Darin,

I just asked for clarification whether it's on a TLS WG agenda for London.
I'm not quite sure this is a right thread to discuss the contents of that draft.
(In fact, I'm pretty sire it isn't.)

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: xima...@gmail.com
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58


On Fri, Mar 9, 2018 at 2:39 AM, Darin Pettis  wrote:
> Artyom,
> Thanks for mentioning the ID and you are right that draft Fenter is the
> supporting problem description.
>
> The reason it was written was to help folks understand why legitimate
> internal out-of-band decryption is still needed on data once it reaches its
> destination and that there isn’t a viable alternative that we are aware of.
> Especially not in-line MitM decryption.  It just doesn’t scale.  The draft
> lists the legitimate internal requirements and speaks to the facts around
> some of the suggestions that have been offered.
>
>  It’s a good read and we are happy to answer questions in advance as needed.
>
> Darin
>
> On Thu, Mar 8, 2018 at 4:11 PM Artyom Gavrichenkov 
> wrote:
>>
>> Hi Sean, Joe,
>>
>> WG also has this at its disposal:
>> https://tools.ietf.org/html/draft-fenter-tls-decryption-00
>> Will that be discussed along with draft-rhrd-tls-tls13-visibility?
>> Those two seem to be rather connected/dependant on each other.
>>
>> | Artyom Gavrichenkov
>> | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
>> | mailto: xima...@gmail.com
>> | fb: ximaera
>> | telegram: xima_era
>> | skype: xima_era
>> | tel. no: +7 916 515 49 58
>>
>>
>> On Thu, Mar 8, 2018 at 12:21 PM, Stephen Farrell
>>  wrote:
>> >
>> > Hi Sean, Joe,
>> >
>> > On 08/03/18 16:20, Sean Turner wrote:
>> >> I’ve posted the draft agendas:
>> >>
>> >> Monday:
>> >>
>> >> https://datatracker.ietf.org/meeting/101/materials/agenda-101-tls-sessb
>> >
>> > That includes:
>> > "
>> > TLS Vizability - Russ & Chairs - 30min
>> >  - 10min draft - Russ
>> >   https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/
>> >  - 10min discussion - Chairs
>> >  - 10min wrap-up - Chairs
>> > "
>> >
>> > Consider this as an objection to that agenda item
>> > being given any time. I also have some questions
>> > below.
>> >
>> > This topic was discussed at length in Prague with a
>> > very clear lack of consensus to consider any work in
>> > that space, despite there being quite a few fans of
>> > doing such work in the room that day. I don't see
>> > that anything has changed in the meantime.
>> >
>> > Russ' draft was discussed on the list last year, also
>> > with (ISTM) no consensus at all to do any work in
>> > that space. (While you didn't make a consensus call,
>> > am I wrong?) The -01 version is not significantly
>> > different from what was discussed on the list so I
>> > see no need for any presentation nor discussion time.
>> >
>> > Given the above, on what basis are meeting attendees
>> > being asked to waste yet more f2f time on this topic?
>> >
>> > And why is another want-it/hate-it exercise useful?
>> >
>> > As chairs, are you going to continually allow the same
>> > topic to be raised, in the face of a very clear lack
>> > of consensus to do anything in this space? If not,
>> > then what's the plan for ending this?
>> >
>> > Thanks,
>> > S.
>> >
>> > PS: I also strongly object to the "visibility" euphemism,
>> > and while that's partly a comment on the draft, it would
>> > also IMO be a significant error to pose any questions to
>> > the WG based on that euphemism.
>> >
>> >
>> > ___
>> > 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls