> On Jul 5, 2015, at 11:46 PM, [email protected] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the DNS PRIVate Exchange Working Group of the 
> IETF.
> 
>        Title           : TLS for DNS: Initiation and Performance 
> Considerations
>        Authors         : Zi Hu
>                          Liang Zhu
>                          John Heidemann
>                          Allison Mankin
>                          Duane Wessels
>                          Paul Hoffman
>       Filename        : draft-ietf-dprive-start-tls-for-dns-01.txt
>       Pages           : 18
>       Date            : 2015-07-05
> 
> Abstract:
>   This document offers an approach to initiating TLS for DNS: use of a
>   dedicated DNS-over-TLS port, and fallback to a mechanism for
>   upgrading a DNS-over-TCP connection over the standard port (TCP/53)
>   to a DNS-over-TLS connection.  Encryption provided by TLS eliminates
>   opportunities for eavesdropping on DNS queries in the network, such
>   as discussed in RFC 7258.  In addition it specifies two usage
>   profiles for DNS-over-TLS.  Finally, it provides advice on
>   performance considerations to minimize overheads from using TCP and
>   TLS with DNS, pertaining to both approaches.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-start-tls-for-dns/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dprive-start-tls-for-dns-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-start-tls-for-dns-01
> 

Working group,

This updated internet draft was submitted last week.  Here are the substantive 
changes since
the -00 version:

- incorporated a number of suggestions and comments from Daniel Kahn Gillmor.
- removed a discussion question on utility of the TO in a UDP message.  There 
was no input from the working group on this point.
- when a client receives TO=0 in response to TO=1 query, they client MAY (was 
SHOULD) use the established
connection for unencrypted queries.
- clarify that when TLS handshake fails, both sides must close the connection.
- rewrote the "established connection" section
- this document no longer makes specific recommendations on idle timeouts.  It 
defers to other documents.
- added reference to TLS fast session resumption and mention of TLS false start 
work-in-progress.
- added an "implementation status" section

Also note that we added a discussion question on the need for both the 
upgrade-based (i.e. TO bit) approach
and the dedicated port approach.  If the working group feels that one approach 
is sufficient, this document
may be simplified.

We believe that this update addresses the working group's concerns and hope 
that the document can progress
to last call soon.

Duane W, on behalf of the draft authors

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to