Re: [Atlas] Status Update

[Russ Housley <[e-mail]>]

In the SAAG session in London, we heard that TCP-AO is not being used.  Sadly, people are still using TCP-MD5.  One thing that TCP-AO offers is the ability to roll from one key to the next without tearing down the TCP connection.  To do that, a table of keys is needed.  I think that the TLS key extraction would be a very sound way to populate the key table automatically.  For example, once per week, TLS could be used to populate daily keys.

Russ


> On Jun 8, 2018, at 9:29 AM, Martin Thomson <[e-mail]> wrote:
> 
> It seems to me that there are two things you might explore, almost
> separately here:
> 
> 1. The definition of new transports for the TLS handshake.  The cases
> I've heard described cover a wide variety of cases with heterogeneous
> hops even within the same example.
> 
> This is something we're (still) grappling with in QUIC, but we've
> reached a point now where the working group believes that
> we have a solid solution.  Talking to the people involved there might
> be sensible.  It's ALSO something that the TAPS working group have
> been pondering in a more abstract sense, which suggests that they
> might have some valuable input.
> 
>> From this I've learned that DTLS and TLS are very different beasts.
> TLS relies on ordered delivery of its handshake messages, but doesn't
> really have any deep relationship with its record layer.  In contrast,
> DTLS doesn't have that reliance, but it has a much closer relationship
> with its record layer (at least in DTLS 1.3 - I'm assuming here that
> new work would not entertain the use of anything less than TLS 1.3).
> 
> 2. Then there is the extraction and use of the shared secret that TLS
> negotiates.  For this, we have examples already in DTLS-SRTP, which
> uses an exporter, and the current QUIC (though this will not be true
> in future).  In using these secrets, we can be a lot more flexible,
> and I suspect that anything the group does here will be much easier to
> reason about than the far more complex handshakey piece.
> 
> My impression was that there were two aspects to the concerns from the
> IESG and IAB.
> 
> The I* was looking to see more enthusiasm for the solutions proposed
> here than was demonstrated (both on the list thus far and in the
> presentation that was given).  In particular, the notion that this
> might be used to circumvent blocking of TLS was problematic.  This was
> inferred from the example given in the presentation and alluded to in
> the charter: devices that can't be configured with trust anchors such
> that they could connect through a MitM in the usual fashion, but want
> to connect anyway.
> 
> They seem to also have wanted a more concrete definition of the
> solutions that were being sought.  The charter Hannes describes is a
> little open-ended and having some more clarity about that would be
> good.
> 
> In any case, I think that it would be valuable to ask for some
> side-meeting time in Montreal
> On Fri, Jun 8, 2018 at 1:44 PM Hannes Tschofenig
> <[e-mail]> wrote:
>> 
>> Hi all,
>> 
>> 
>> 
>> Owen and I submitted another BoF proposal to the IESG based on the feedback from the last IETF meeting.
>> 
>> 
>> 
>> Here is the most recent charter text we came up with:
>> 
>> ---
>> 
>> There are multiple scenarios where clients and servers need to negotiate shared encryption keys and establish secure, authenticated, integrity-protected, end-to-end encrypted sessions at the application layer over untrusted transport. There are a proliferation of transport protocols and mechanisms in use today across web and IoT use cases including, but not limited to, TCP, UDP, IP, Bluetooth and Zigbee. Additionally, network topologies often include middleboxes and proxies that terminate transport layer connections from clients and re-originate new transport layer connections towards the servers. From the clients and servers perspective, these transport layer proxy functions are untrusted and application data must be protected and encrypted, and not exposed to these proxies. There are multiple potential mechanisms that could be considered for negotiation of encryption keys, and establishment of end-to-end encrypted sessions at the application layer between clients and servers, and
>  this working group proposes use of existing (D)TLS protocols and stacks.
>> 
>> 
>> 
>> This working group proposes reuse of (D)TLS at the application layer as a simple and straightforward means of achieving the security and implementation goals. The primary purpose of the working group is to develop specifications defining how (D)TLS can be leveraged at the application layer (i.e. Application Layer TLS or ATLS) to establish end-to-end encrypted sessions over a multitude of different transports.
>> 
>> 
>> 
>> Additionally, during development of ATLS specifications, the working group will consider and address concerns such as:
>> 
>> 
>> 
>> o complex, multi-hop and lossy transport topologies
>> 
>> o (D)TLS record fragmentation at the transport layer
>> 
>> o middlebox operators whose goals include interception of application layer data
>> 
>> 
>> 
>> The working group will engage with other relevant working groups across the Applications and Real-Time Area (art), Security Area (sec) and Transport Area (tsv), and one of the goals of this working group is to explicitly identity all related working groups that must be consulted during ATLS specifications development.
>> 
>> ---
>> 
>> 
>> 
>> There do not seem to be minutes available from the IESG/IAB BoF discussions and how they reached their conclusions. So, we can only report what has been told to us by proxy.
>> 
>> 
>> 
>> In any case, the IESG rejected the BoF proposal.
>> 
>> 
>> 
>> The impression from the IESG was that the Bar BOF in London produced mixed feelings and that there was no activity on the list afterwards.
>> 
>> Another comment was that the required standardization effort is too small to justify the setup of an entire working group.
>> 
>> 
>> 
>> At first, this sounds a bit negative. On the other hand, we have two implementations right now. While they need to be polished I believe this is something we could go forward with.
>> 
>> 
>> 
>> Ciao
>> Hannes
>> 
>> 
>> 
>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>> _______________________________________________
>> Atlas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/atlas
> 
> _______________________________________________
> Atlas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/atlas