Subject: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-08.txt

From: Sara Dickinson <[email-masked]>
Date: Wed, 3 Aug 2016 16:23:50 +0100

Hi All, 

I think the recent changes have moved this draft in the right direction, but I agree with other reviewers that it could still become more aligned with the other related drafts. So I’ve done quite a detailed review with 2 main goals in mind:

1) Increase consistency between this draft and RFC7858
2) Align it better with the most recent version of the draft-ietf-dprive-dtls-and-tls-profiles draft

My strong preference would be to see these changes made before the document progressed to WGLC, as I think they increase the overall readability. 

With regard to the separate https://tools.ietf.org/html/draft-wing-dprive-profile-and-msg-flows-01 I’ll re-iterate my question from the Yokohama WG: Is there anything DNS specific in the draft? I don’t recall anything particularly DNS specific. I definitely see value in a draft comparing message flows between TLS and DTLS in general, but my feeling is it might be better progressed though another working group with more (D)TLS experts - TLS or UTA?

On the topic of Experimental vs Standards I support the position that implementation work is necessary for this to be considered Standards Track. In particularI think there are 2 areas that need to be directly informed by implementation experience
1) DTLS Session management 
2) Reference implementation of message size calculation and fallback scenarios

Comments on this draft
---------------------------------

Title/Acronym: 

- My suggestion is to change the title to "Specification for DNS over Datagram Transport Layer Security (DTLS)” for consistency with RFC7858, which is called “Specification for DNS over Transport Layer Security (TLS)“ and then also drop the suggested acronym "(DNSoD, pronounced "dee-eon-sod”)”. In draft-ietf-dprive-dtls-and-tls-profiles we use DNS-over-(D)TLS throughout so calling this mechanism simply DNS-over-DTLS feels more consistent.

Abstract: 

- “AS DNS needs to remain fast” - suggest “As latency is critical for DNS” 

1. Introduction:

- Second bullet point, last paragraph: I think it is currently correct that TCP Fast open is not yet ubiquitous but given the recent significant deployment efforts I’m not sure that will remain true for long.  Also, TFO is now available on Windows, Linux, OS X and (server side) FreeBSD.

1.1 Relationship to TCP Queries and to DNSSEC

- s/DNS over TCP could be protected with TLS/DNS over TCP can be protected with TLS/

- I suggest adding an additional paragraph after the first one here with wording similar to that below. I think this is necessary to avoid the kind of confusion that plagued the requirement to implement DNS-over-TCP for many years, or an intermediate state where only partial privacy is available:
“DNS-over-DTLS alone cannot provide privacy for DNS messages in all circumstances, specifically when the DNS-over-DTLS response is larger than the path MTU. In such situations the DNS server will respond with a truncated response (see Section 4). Therefore DNS clients and servers that implement DNS-over-DTLS MUST also implement DNS-over-TLS in order to provide privacy for clients that desire Strict Privacy as described in [draft-ietf-dprive-dtls-and-tls-profiles].”

3.1 Session Initiation

- “DNSoD MUST run over standard UDP port 853 as defined in Section 7.”
—  Interesting. This is a substantially different statement to that made wrt DNS-over-TCP in Section 3.1 of RFC7858, which allows flexibility run over other ports (but not to use port 53). So this seems inconsistent and also more restrictive. It would be nice to have some justification for this if this is the requirement, otherwise this section could use very similar text to that used in RFC7858 here? 
-- I would like to see a statement that clients and servers MUST NOT use port 853 for clear text UDP messages.

- s/The host should determine if the DNS server/The DNS client should determine if the DNS server/

3.2 DTLS Handshake and Authentication

- s/in the event the DNS server upgrades to support DNSoD/to discover if DNS-over-DTLS service becomes available from the DNS server/

- I’d also like to see some statement about how many concurrent DTLS sessions a client should establish to a particular DNS Server (just one?). 

- Second paragraph: It seems the first 3 sentences here are repeating the motivation for authentication already provided in the Introduction. I suggest replacing them with the text “ The client will then authenticate the server, if required. “

3.3 Established Sessions

- Is there anything additional here that can be said about expected session lifetimes or idle timeouts? Is it expected that clients keep session open indefinitely until some sort of error is encountered or can some sort of reasonable idle timeout be suggested? Is there any expectation about whether the client or server typically terminates a session?

- There is a diagram here of a “Message Flow for Full Handshake Issuing New Session Ticket” but is doesn’t appear to be referenced from the text at all - is there a specific reason to include this flow here (I think it is a standard DTLS message flow)? I suggest either to give it some context or remove it.

4. Performance Considerations 

- The first and third paragraphs overlap with the recommendations already made in Section 11 of the draft-ietf-dprive-dtls-and-tls-profiles draft, so perhaps they can be removed or changed to make any DTLS specific points?

- “Since pipelined responses can arrive out of order” - I think the word ‘pipelined’ was accidentally picked up by re-using the text in RFC7858. For DTLS I think it is more correct to just say “Since responses within a DTLS session can arrive out of order “?

- Fourth Paragraph:
— I’m not sure that the discussion of truncated responses is purely a performance issue, I believe is is a protocol issue so would suggest moving this to a section of its own?

-- Question: What does a server do if the client doesn’t send an EDNS0 option? 

-- "The DNS server must ensure that the DNS response size does not exceed the Path MTU”    s/must/MUST?

-- “If the DNS server's response were to exceed that calculated value, the server sends a response...”  Is there a reason this isn't ‘the server MUST send a response”?

-- I do think there is a DTLS Usage Profile specific point to make related to this, which is that if a client gets a truncated answer over DTLS it could choose to fallback to UDP/TCP instead of TLS _if_ it were using an Opportunistic profile which would result in a kind of ‘hybrid’ security.  I don’t really see any advantage in that if TLS is available, but the last sentence is unclear on this possibility, suggesting only TLS can be used - which is correct for Strict Privacy but perhaps not (at least technically) for Opportunistic. This feel worthy of some discussion. 

6. Usage

The draft-ietf-dprive-dtls-and-tls-profiles draft now includes a fairly detailed comparison of Strict and Opportunistic privacy so I wonder if this section can be replaced with a reference to that document, unless there is anything DTLS specific that needs to be said here?

8. Security Considerations

- "The guidance given in [RFC7525] must be followed to avoid attacks on DTLS.”   s/must/MUST or SHOULD?

- “For servers with no connection history…” I think this sentence can also be removed since it is more fully covered in the draft-ietf-dprive-dtls-and-tls-profiles draft.

- “Once a DNSoD client has established
   a security association with a particular DNS server, and outstanding
   normal DNS queries with that server (if any) have been received, the
   DNSoD client MUST ignore any subsequent normal DNS responses from
   that server, as all subsequent responses should be encrypted.”
I think this text is a hangover from the earlier draft when port 53 was used. If clarification is added in section 3.1 then I think clear text and DTLS should only ever happen on separate ports when communicating with a given server?

Minor editorial nits:

- There are several places throughout the document where a space separates a reference from a following punctuation mark (e.g. end of the first and last sentences of the Introduction).
- Abstract: Second paragraph, first sentence:  This sentence starts and ends with very similar phrases which I’m not sure are both needed?
- Introduction: Missing ‘The’ at the start of last sentence of first paragraph?
- Section 3.2: First sentence:  s/with DTLS handshake/with the DTLS handshake/
- Section 3.3: s/When a user of DTLS wishes to send an DNS message, it delivers it to the DTLS implementation/When a user of DTLS wishes to send a DNS message, the data is delivered to the DTLS implementation/
- Sestion 3.4: s/DNSod client and server MUST/DNS-over-DTLS clients and servers MUST/
- Section 3.4: s/DTLS session is terminated/A DTLS session is terminated/
- Section 4:    s/To reduce number of/To reduce the number of/
- Section 4:    s/DNS client and server can use raw public keys [] or/DNS clients and servers can use raw public keys [] and/
- Section 4:    s/Path MTU MUST be greater than equal to/Path MTU MUST be greater than or equal to/
- Section 5:    s/DTLS client receives authenticated/DTLS client receives an authenticated/

Regards

Sara.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 5 Aug 2016 02:47:54 +0000

Hi Sara,

Thanks for the review. Please see inline

> -----Original Message-----
> From: dns-privacy [mailto:[email-masked]] On Behalf Of Sara
> Dickinson
> Sent: Wednesday, August 3, 2016 8:54 PM
> To: [email-masked]
> Subject: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-08.txt
> 
> Hi All,
> 
> I think the recent changes have moved this draft in the right direction, but I
> agree with other reviewers that it could still become more aligned with the
> other related drafts. So I’ve done quite a detailed review with 2 main goals in
> mind:
> 
> My strong preference would be to see these changes made before the
> document progressed to WGLC, as I think they increase the overall readability.
> 
> With regard to the separate https://tools.ietf.org/html/draft-wing-dprive-
> profile-and-msg-flows-01 I’ll re-iterate my question from the Yokohama WG:
> Is there anything DNS specific in the draft? I don’t recall anything particularly
> DNS specific. I definitely see value in a draft comparing message flows
> between TLS and DTLS in general, but my feeling is it might be better
> progressed though another working group with more (D)TLS experts - TLS or
> UTA ?

I don't think other WG will care enough for this draft, maybe the chairs can request reviewers from the above WG's.

> 
> On the topic of Experimental vs Standards I support the position that
> implementation work is necessary for this to be considered Standards Track.
> In particularI think there are 2 areas that need to be directly informed by
> implementation experience
> - My suggestion is to change the title to "Specification for DNS over Datagram
> Transport Layer Security (DTLS)” for consistency with RFC7858, which is called
> “Specification for DNS over Transport Layer Security (TLS)“ and 

Changed.

> then also drop
> the suggested acronym "(DNSoD, pronounced "dee-eon-sod”)”. In draft-ietf-
> dprive-dtls-and-tls-profiles we use DNS-over-(D)TLS throughout so calling this
> mechanism simply DNS-over-DTLS feels more consistent.

The acronym was added as it sounded easy to pronounce.

> - “AS DNS needs to remain fast” - suggest “As latency is critical for DNS”

Updated.

> 
> 
> 1. Introduction:
> 
> - Second bullet point, last paragraph: I think it is currently correct that TCP
> Fast open is not yet ubiquitous but given the recent significant deployment
> efforts I’m not sure that will remain true for long.  Also, TFO is now available
> on Windows, Linux, OS X and (server side) FreeBSD.

Removed the second line in the last paragraph.

> - s/DNS over TCP could be protected with TLS/DNS over TCP can be protected

Fixed.

> 
> - I suggest adding an additional paragraph after the first one here with
> wording similar to that below. I think this is necessary to avoid the kind of
> confusion that plagued the requirement to implement DNS-over-TCP for many
> years, or an intermediate state where only partial privacy is available:
> “DNS-over-DTLS alone cannot provide privacy for DNS messages in all
> circumstances, specifically when the DNS-over-DTLS response is larger than
> the path MTU. In such situations the DNS server will respond with a truncated
> response (see Section 4). Therefore DNS clients and servers that implement
> DNS-over-DTLS MUST also implement DNS-over-TLS in order to provide
> privacy for clients that desire Strict Privacy as described in [draft-ietf-dprive-
> dtls-and-tls-profiles].”

Good point, updated.

> —  Interesting. This is a substantially different statement to that made wrt
> DNS-over-TCP in Section 3.1 of RFC7858, which allows flexibility run over
> other ports (but not to use port 53). So this seems inconsistent and also more
> restrictive. It would be nice to have some justification for this if this is the
> requirement, otherwise this section could use very similar text to that used in
> RFC7858 here?

Used text similar to RFC7858.

> 853 for clear text UDP messages.

Added.

> determine if the DNS server/

Fixed.

> - s/in the event the DNS server upgrades to support DNSoD/to discover if DNS-
> over-DTLS service becomes available from the DNS server/

Replaced.

> 
> - I’d also like to see some statement about how many concurrent DTLS
> sessions a client should establish to a particular DNS Server (just one?).

Yes, one DTLS session is sufficient. Its already discussed in Section 3.3
<snip>To reduce client and server workload, clients SHOULD re-use the DTLS session. A single DTLS session can be used to send multiple DNS requests and receive multiple DNS responses.</snip>

> 
> - Second paragraph: It seems the first 3 sentences here are repeating the
> motivation for authentication already provided in the Introduction. I suggest
> replacing them with the text “ The client will then authenticate the server, if
> required. “

I think those 3 sentences are still required to understand the importance of authenticating the DNS server.

> 
> 3.3 Established Sessions
> 
> - Is there anything additional here that can be said about expected session
> lifetimes or idle timeouts? Is it expected that clients keep session open
> indefinitely until some sort of error is encountered or can some sort of
> reasonable idle timeout be suggested? Is there any expectation about whether
> the client or server typically terminates a session?

Yes, updated draft.
NEW:
In between normal DNS traffic while the communication to the DNS server is quiescent, the DNS client may want to probe the server to ensure it has maintained cryptographic state. Such probes can also keep alive firewall or NAT bindings. This probing reduces the frequency of needing a new handshake when a DNS query needs to be resolved, improving the user experience at the cost of bandwidth and processing time.  If the server has lost state, a DTLS handshake needs to be initiated with the server.

> 
> - There is a diagram here of a “Message Flow for Full Handshake Issuing New
> Session Ticket” but is doesn’t appear to be referenced from the text at all - is
> there a specific reason to include this flow here (I think it is a standard DTLS
> message flow)? I suggest either to give it some context or remove it.

Added supporting text.

> - The first and third paragraphs overlap with the recommendations already
> made in Section 11 of the draft-ietf-dprive-dtls-and-tls-profiles draft, so
> perhaps they can be removed or changed to make any DTLS specific points ?

Added reference to Section 11 of profile draft.

> 
> - “Since pipelined responses can arrive out of order” - I think the word
> ‘pipelined’ was accidentally picked up by re-using the text in RFC7858. For
> DTLS I think it is more correct to just say “Since responses within a DTLS
> session can arrive out of order “?

Updated.

> 
> - Fourth Paragraph:
> — I’m not sure that the discussion of truncated responses is purely a
> performance issue, I believe is is a protocol issue so would suggest moving
> this to a section of its own?

Yes, added new section.

> -- Question: What does a server do if the client doesn’t send an EDNS0 option?

The maximum DNS response size of 512 bytes plus DTLS overhead will be well within the Path MTU. 
> the Path MTU”    s/must/MUST?

Done.

> 
> -- “If the DNS server's response were to exceed that calculated value, the
> server sends a response...”  Is there a reason this isn't ‘the server MUST send a
> response”?

No, updated above line to use "MUST".

> 
> -- I do think there is a DTLS Usage Profile specific point to make related to this,
> which is that if a client gets a truncated answer over DTLS it could choose to
> fallback to UDP/TCP instead of TLS _if_ it were using an Opportunistic profile
> which would result in a kind of ‘hybrid’ security.  

In Opportunistic profile, if server sends truncated response then 
DNS client should first try TLS and if the TLS handshake fails then fallback to TCP.

> I don’t really see any
> advantage in that if TLS is available, but the last sentence is unclear on this
> possibility, suggesting only TLS can be used - which is correct for Strict Privacy
> but perhaps not (at least technically) for Opportunistic. This feel worthy of
> some discussion.

Added following line:
If DNS-over-TLS connection fails and the client is using Opportunistic Privacy profile then the client can fallback to DNS-over-TCP. DNS client can setup both DNSoD and DNS-over-TLS connections in parallel, to reduce the latency to send DNS queries over DNS-over-TLS if the DNS response is truncated over the DNSoD and the client needs the entire response.

 > 
> 6. Usage
> 
> The draft-ietf-dprive-dtls-and-tls-profiles draft now includes a fairly detailed
> comparison of Strict and Opportunistic privacy so I wonder if this section can
> be replaced with a reference to that document, unless there is anything DTLS
> specific that needs to be said here?

Updated section to point to the profiles draft.

> DTLS.”   s/must/MUST or SHOULD?

Fixed.

> 
> - “For servers with no connection history…” I think this sentence can also be
> removed since it is more fully covered in the draft-ietf-dprive-dtls-and-tls-
> profiles draft.

I don’t think it's discussed in profile draft, please check.

> I think this text is a hangover from the earlier draft when port 53 was used. 

No, the above line explains that if the DNS client is using DNSoD it must not accept plain text DNS responses arriving on any port. 
Added more details to clarify.

> If
> clarification is added in section 3.1 then I think clear text and DTLS should only
> ever happen on separate ports when communicating with a given server?
> 
> 
> Minor editorial nits:
> 
> - There are several places throughout the document where a space separates
> a reference from a following punctuation mark (e.g. end of the first and last
> sentences of the Introduction).
> - Abstract: Second paragraph, first sentence:  This sentence starts and ends
> with very similar phrases which I’m not sure are both needed?
> - Section 3.3: s/When a user of DTLS wishes to send an DNS message, it
> delivers it to the DTLS implementation/When a user of DTLS wishes to send a
> DNS message, the data is delivered to the DTLS implementation/
> - Section 4:    s/DNS client and server can use raw public keys [] or/DNS clients
> and servers can use raw public keys [] and/

Updated draft to address all above nits.

Best Regards,
-Tiru

> 
> Regards
> 
> Sara.
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 8 Aug 2016 13:21:49 +0100

> On 5 Aug 2016, at 03:47, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> 
> Hi Sara,
> 

Hi Tiru, 

Thanks for the detailed response. 

> I don't think other WG will care enough for this draft, maybe the chairs can request reviewers from the above WG’s.

I’d be interested to know what others think about this. 

> The acronym was added as it sounded easy to pronounce.

I haven’t ever heard that acronym used -  I’ve only heard people talk about DNS-over-DTLS :-)

If the acronym is retained then I think in a pass is needed though the document to improve consistency because at the moment both DNSoD and DNS-over-DTLS are used in different sections to (I think) mean the same thing.

> Removed the second line in the last paragraph.

I think the reference to TFO is still relevant and shouldn’t be completely removed, how about something like:

“ DTLS session resumption consumes 1 round trip whereas TLS session
    resumption can start only after TCP handshake is complete. However TCP Fast Open [
   RFC7413] can eliminate 1-RTT in the latter case. “

> <snip>To reduce client and server workload, clients SHOULD re-use the DTLS session. A single DTLS session can be used to send multiple DNS requests and receive multiple DNS responses.</snip>

But this doesn’t explicitly say a client SHOULD only use one session. How about considering adding a section based on 6.2.2 of RFC7766 (https://tools.ietf.org/html/rfc7766#section-6.2.2) to cover this? 

> In between normal DNS traffic while the communication to the DNS server is quiescent,

You could re-use/reference the definition of an idle DNS-over-TCP session as defined in RFC7766 here for clarity and consistency?

> the DNS client may want to probe the server to ensure it has maintained cryptographic state. Such probes can also keep alive firewall or NAT bindings. This probing reduces the frequency of needing a new handshake when a DNS query needs to be resolved, improving the user experience at the cost of bandwidth and processing time.  

I’m not clear what kind of ‘probing’ you are suggesting here? A dummy DNS message or some sort of keepalive mechanism - can you expand please? 

> The maximum DNS response size of 512 bytes plus DTLS overhead will be well within the Path MTU. 

Sorry - I meant that adding a sentence on this to the draft might be helpful to remove ambiguity. 

> If DNS-over-TLS connection fails and the client is using Opportunistic Privacy profile then the client can fallback to DNS-over-TCP.

On re-reading this and the profiles draft (draft-ietf-dprive-dtls-and-tls-profiles), this seems rather specific. I’m leaning towards keeping the discussion protocol neutral, as we did in the profiles draft... but I’d like to see some more feedback on this...

There is, of course, a small subset of DNS responses that are too large to be sent using DTLS, but could be send plain text over UDP given the same MTU. The TC bit in this scenario simply signals to the client that the response is too large for DTLS, but of course this signalling can’t convey any more detailed information. Again, it is a bit of a corner case but a question in my mind is how detailed this draft should be in specifying the fallback mechanisms? 

One approach would be something like: 

“Upon receiving a response with the TC bit set and wanting to
   receive the entire response, the client behaviour is governed by the current Usage profile 
   [draft-ietf-dprive-dtls-and-tls-profiles]. For Strict Privacy the client MUST only send
   a new DNS request for the same resource record over an encrypted transport
  (e.g. DNS-over-TLS [RFC7858]). Clients using Opportunistic Privacy SHOULD 
  try for the best case  (an encrypted and authenticated transport) but MAY fallback to intermediate cases and eventually the worst case
   scenario (clear text) in order to obtain a response”  

This is then almost identical to the text in section 4.2 of the profiles draft but allows clients flexibility. 

> DNS client can setup both DNSoD and DNS-over-TLS connections in parallel, to reduce the latency to send DNS queries over DNS-over-TLS if the DNS response is truncated over the DNSoD and the client needs the entire response.

Ah, ‘parallel connections’  is a new idea and warrants discussion. It also seems to be spilling over into the area of preference between the protocols, which I think I would argue is out of scope for this document. Additionally it occurs to me that using DNS-over-DTLS and then just using ‘one-shot’ TLS for truncated messages is really paying a price (more so than falling back to TCP from UDP). So perhaps it makes more sense to use the above rather neutral text and defer this discussion to another document that can include implementation and deployment experience?  

> I don’t think it's discussed in profile draft, please check.

I read this as just another description of selecting behaviour depending on the Usage Profile (called I think Privacy Profile here) where b) is Opportunistic and c) is Strict. I don’t think is says anything new above that unless I have mis-read or misunderstood?

> Added more details to clarify.

Can you send the updated text please - a few more thoughts occur to me here but perhaps they are addressed in the new text? 

Sara.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 8 Aug 2016 16:13:25 +0000

Hi Sara,

Please see inline

From: Sara Dickinson [mailto:[email-masked]]
Sent: Monday, August 8, 2016 5:52 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>
Cc: [email-masked]
Subject: RE [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-08.txt

On 5 Aug 2016, at 03:47, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sara,

Hi Tiru,

then also drop

[TR] Okay, removed the acronym ☺

1. Introduction:

[TR] Updated.

[TR] Done.

3.3 Established Sessions

Yes, updated draft.
NEW:

You could re-use/reference the definition of an idle DNS-over-TCP session as defined in RFC7766 here for clarity and consistency ?

I’m not clear what kind of ‘probing’ you are suggesting here? A dummy DNS message or some sort of keepalive mechanism - can you expand please ?

[TR] DTLS heartbeat is used for probing, updated text. I am not sure what to pick from RFC7766 (edns-tcp-keepalive is specific to TCP) ?

[TR] Okay, added the following lines: If the DNS client does set the EDNS0 option defined in [RFC6891] then the maximum DNS response size of 512 bytes plus DTLS overhead will be well within the Path MTU. If the Path MTU is not known, an IP MTU of 1280 bytes SHOULD be assumed.

I don’t really see any

Added following line:

[TR] Proposed text looks good, updated draft.

Ah, ‘parallel connections’  is a new idea and warrants discussion. It also seems to be spilling over into the area of preference between the protocols, which I think I would argue is out of scope for this document. Additionally it occurs to me that using DNS-over-DTLS and then just using ‘one-shot’ TLS for truncated messages is really paying a price (more so than falling back to TCP from UDP). So perhaps it makes more sense to use the above rather neutral text and defer this discussion to another document that can include implementation and deployment experience ?

[TR] Removed above line from my local copy.

[TR] Removed.

Can you send the updated text please - a few more thoughts occur to me here but perhaps they are addressed in the new text ?

[TR] Sure, will do.

-Tiru

Sara.

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 10 Aug 2016 17:59:55 -0700

(Glad to see the interaction between Sara and Tiru; responding on just 
one point.)

On 8 Aug 2016, at 5:21, Sara Dickinson wrote:

>>> With regard to the separate 
>>> https://tools.ietf.org/html/draft-wing-dprive-
>> I don't think other WG will care enough for this draft, maybe the 
>> chairs can request reviewers from the above WG’s.
>

I disagree with Tiru: I think other WGs *will* care about it. It could 
go in the TLS WG, but I suspect it will get moldy there waiting for TLS 
1.3 to finish. I think SAAG could take this on, or maybe spin up a 
short, narrow WG for it.

--Paul Hoffman