[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] TSV ART review of draft-ietf-tls-sni-encryption
From: Bernard Aboba <bernard_aboba () hotmail ! com>
Date: 2019-09-10 18:52:54
Message-ID: BYAPR06MB55585C7E48E934D49EBA4CBD93B60 () BYAPR06MB5558 ! namprd06 ! prod ! outlook ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
On Sep 10, 2019, at 11:50 AM, Christian Huitema \
<huitema@huitema.net<mailto:huitema@huitema.net>> wrote:
Thanks for the feedback, Bernard. We already fixed in the editor copy some of the \
issues that you described based on other feedback received during last call, but not \
all. Your comments about section 3.7.1 and section 5 are interesting. I like your \
suggestion of moving some of the text from section 5 to the introduction and believe \
that it will improve the document.
Regarding section 3.7.1, you suggest adding a comment on related work, and perhaps \
moving some of the discussion of ALPN there. I understand the rationale, but I am a \
bit worried about going too far there -- the current text reflects discussions and \
feedback on the TLS list. Also, if we did add a section on related work we would \
probably need to reference the deployment of encrypted DNS services, and I am a bit \
worried about doing that late in the production cycle. How about a compromise, such \
as pointing the issue in the introduction with a forward reference to section 3.7.1?
That would be fine.
-- Christian Huitema
On 9/9/2019 12:48 PM, Bernard Aboba wrote:
Document: draft-ietf-tls-sni-encryption
Reviewer: Bernard Aboba
Review result: Ready with Nits
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.
When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org<mailto:tsv-art@ietf.org> if you reply to or forward this review.
I have not identified any transport related issues.
NITS
Expansion of acronyms on first use:
Abstract: TLS
Section 1: DNS
Section 2.1: ISP, QoS, MITM
Section 2
s/mutiple/multiple/
Section 2.1
s/fradulent/fraudulent/
Section 3.6
The downside is the the
client will not verify the identity of the fronting service with
risks discussed in , but solutions will have to mitigate this risks.
[BA] Several problems with this sentence:
s/the the/the/
s/this risks/the risk/
s/discussed in ,/discussed in [REF-TBD],/
Section 3.7.1
This section seems somewhat out of place in a section on Security
and Privacy Requirements for SNI Encryption, given that it relates
to hiding of the ALPN, and the text admits a weak case for linking
the two problems:
Using the same technique for hiding the ALPN and encrypting the SNI
may result in excess complexity. It might be preferable to encrypt
these independently.
You might consider moving this section to Section 4.3.1, under Section 4.3
Related Work.
Section 5
The first paragraph of this section strikes me as being potentially better
suited to inclusion in Section 1 Introduction.
Replacing clear text SNI transmission by an encrypted variant will
improve the privacy and reliability of TLS connections, but the
design of proper SNI encryption solutions is difficult. This
document does not present the design of a solution, but provides
guidelines for evaluating proposed solutions.
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
<div dir="ltr"></div>
<div dir="ltr">On Sep 10, 2019, at 11:50 AM, Christian Huitema <<a \
href="mailto:huitema@huitema.net">huitema@huitema.net</a>> wrote:</div> <div \
dir="ltr"><br> </div>
<blockquote type="cite">
<div dir="ltr">
<p>Thanks for the feedback, Bernard. We already fixed in the editor copy some of the \
issues that you described based on other feedback received during last call, but not \
all. Your comments about section 3.7.1 and section 5 are interesting. I like your \
suggestion of moving some of the text from section 5 to the introduction and believe \
that it will improve the document.<br> </p>
<p><br>
</p>
<p>Regarding section 3.7.1, you suggest adding a comment on related work, and perhaps \
moving some of the discussion of ALPN there. I understand the rationale, but I am a \
bit worried about going too far there -- the current text reflects discussions and \
feedback on the TLS list. Also, if we did add a section on related work we would \
probably need to reference the deployment of encrypted DNS services, and I am a bit \
worried about doing that late in the production cycle. How about a compromise, such \
as pointing the issue in the introduction with a forward reference to section \
3.7.1?</p> </div>
</blockquote>
<div><br>
</div>
That would be fine.<br>
<blockquote type="cite">
<div dir="ltr">
<p><br>
</p>
<p>-- Christian Huitema<br>
</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 9/9/2019 12:48 PM, Bernard Aboba wrote:<br>
</div>
<blockquote type="cite" \
cite="mid:BYAPR06MB55586171004B46D9F92E1EFC93B70@BYAPR06MB5558.namprd06.prod.outlook.com">
<div style="font-family: Calibri, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<span>Document: draft-ietf-tls-sni-encryption</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<span>Reviewer: Bernard Aboba<br>
</span>
<div>Review result: Ready with Nits<br>
</div>
<div><br>
</div>
<div>This document has been reviewed as part of the transport area review team's<br>
</div>
<div>ongoing effort to review key IETF documents. These comments were written<br>
</div>
<div>primarily for the transport area directors, but are copied to the document's<br>
</div>
<div>authors and WG to allow them to address any issues raised and also to the \
IETF<br> </div>
<div>discussion list for information.<br>
</div>
<div><br>
</div>
<div>When done at the time of IETF Last Call, the authors should consider this<br>
</div>
<div>review as part of the last-call comments they receive. Please always CC<br>
</div>
<div><a class="moz-txt-link-abbreviated" \
href="mailto:tsv-art@ietf.org">tsv-art@ietf.org</a> if you reply to or forward this \
review.<br> </div>
<div><br>
</div>
<div>I have not identified any transport related issues.<br>
</div>
<div><br>
</div>
<div>NITS<br>
</div>
<div><br>
</div>
<div>Expansion of acronyms on first use:<br>
</div>
<div><br>
</div>
<div>Abstract: TLS<br>
</div>
<div>Section 1: DNS<br>
</div>
<div>Section 2.1: ISP, QoS, MITM<br>
</div>
<div><br>
</div>
<div>Section 2<br>
</div>
<div><br>
</div>
<div>s/mutiple/multiple/<br>
</div>
<div><br>
</div>
<div>Section 2.1<br>
</div>
<div><br>
</div>
<div>s/fradulent/fraudulent/<br>
</div>
<div><br>
</div>
<div>Section 3.6<br>
</div>
<div><br>
</div>
<div> The downside is the the<br>
</div>
<div> client will not verify the identity of the fronting service \
with<br> </div>
<div> risks discussed in , but solutions will have to mitigate this \
risks.<br> </div>
<div><br>
</div>
<div>[BA] Several problems with this sentence:<br>
</div>
<div><br>
</div>
<div>s/the the/the/<br>
</div>
<div>s/this risks/the risk/<br>
</div>
<div>s/discussed in ,/discussed in [REF-TBD],/<br>
</div>
<div><br>
</div>
<div>Section 3.7.1<br>
</div>
<div><br>
</div>
<div>This section seems somewhat out of place in a section on Security<br>
</div>
<div>and Privacy Requirements for SNI Encryption, given that it relates<br>
</div>
<div>to hiding of the ALPN, and the text admits a weak case for linking<br>
</div>
<div>the two problems: <br>
</div>
<div><br>
</div>
<div> Using the same technique for hiding the ALPN and encrypting the \
SNI<br> </div>
<div> may result in excess complexity. It might be preferable to \
encrypt<br> </div>
<div> these independently.<br>
</div>
<div><br>
</div>
<div>You might consider moving this section to Section 4.3.1, under Section 4.3<br>
</div>
<div>Related Work. <br>
</div>
<div><br>
</div>
<div>Section 5<br>
</div>
<div><br>
</div>
<div>The first paragraph of this section strikes me as being potentially better<br>
</div>
<div>suited to inclusion in Section 1 Introduction. <br>
</div>
<div><br>
</div>
<div> Replacing clear text SNI transmission by an encrypted variant \
will<br> </div>
<div> improve the privacy and reliability of TLS connections, but the<br>
</div>
<div> design of proper SNI encryption solutions is difficult. \
This<br> </div>
<div> document does not present the design of a solution, but \
provides<br> </div>
<div> guidelines for evaluating proposed solutions.<br>
</div>
<span></span><br>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--===============4498831799093511232==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic