Re: [TLS] Adam Roach's Yes on draft-ietf-tls-sni-encryption-05: (with COMMENT)

[Christian Huitema <[e-mail]>]

Due to my moderately competent use of GitHub, draft-06 does not include 
the resolution of Mirja's comments. That will be part of the next draft. 
Sorry.

-- Christian Huitema

On 9/18/2019 2:09 PM, Christian Huitema wrote:
> OK, I just submitted draft-06. As the automated message says:
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-06
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sni-encryption-06
>
> I am going to address the pending comments soon.
>
> -- Christian Huitema
>
> On 9/18/2019 11:27 AM, Benjamin Kaduk wrote:
>> I don't think there's going to be a huge practical difference between
>> pushing a new rev now with the editorial fixes vs. waiting.  My personal
>> inclination is to push the new rev now, acknowledging that another rev
>> after that will likely be needed as well.
>>
>> -Ben
>>
>> On Wed, Sep 18, 2019 at 04:18:03PM -0500, Adam Roach wrote:
>>> No worries!
>>>
>>> I'd work with the responsible AD to coordinate when to publish a new
>>> version.
>>>
>>> I do have one comment below -- regarding the multi-party security
>>> context -- that isn't really editorial and which isn't addressed in the
>>> github version. Do you have any thoughts on it? Am I just missing
>>> something obvious?
>>>
>>> /a
>>>
>>> On 9/18/19 4:10 PM, Christian Huitema wrote:
>>>> Thanks, Adam
>>>>
>>>> I appreciate the feedback, and in fact I need to apologize. We have a
>>>> new version of the draft ready at
>>>> https://github.com/tlswg/sniencryption, which takes into account the
>>>> comments received before Saturday 15, but does not take into 
>>>> account the
>>>> latest round of comments from Alissa, Éric and Roman. It resolves 
>>>> almost
>>>> all the nits that many of you have noticed. I probably hesitated too
>>>> long before publishing a new version of the draft. I knew the 
>>>> ballot was
>>>> in progress, and I was trying to not force everybody to read the 
>>>> draft a
>>>> second time. Also, I was concerned that comments would keep coming as
>>>> long as the ballot progressed, and I kind of hoped resolving all of 
>>>> them
>>>> before cutting a new version. But then, several of you end up 
>>>> stumbling
>>>> on the same issues that are already fixed in the editor copy. My bad.
>>>>
>>>> At that point, I could either publish a new draft version right 
>>>> know, or
>>>> wait a couple of days and address the last comments. I wonder what is
>>>> best for the IESG members. Any opinion?
>>>>
>>>> -- Christian Huitema
>>>>
>>>>
>>>>
>>>> On 9/17/2019 7:55 PM, Adam Roach via Datatracker wrote:
>>>>> Adam Roach has entered the following ballot position for
>>>>> draft-ietf-tls-sni-encryption-05: Yes
>>>>>
>>>>> 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-sni-encryption/
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------- 
>>>>>
>>>>> COMMENT:
>>>>> ---------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>>
>>>>> Thanks to everyone who worked on this. It seems that it will be a 
>>>>> useful
>>>>> tool for evaluating potential solutions.
>>>>>
>>>>> --------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> §3.1:
>>>>>
>>>>>>    Regardless of the encryption used,
>>>>>>    these designs can be broken by a simple replay attack, which 
>>>>>> works as
>>>>>>    follow:
>>>>> Nit: "...as follows:"
>>>>>
>>>>> --------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> §3.6:
>>>>>
>>>>>>    These solutions offer more protection against a Man-In-The-
>>>>>>    Middle attack by the fronting service.  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.
>>>>> This final sentence appears to be missing some kind of citation 
>>>>> before the
>>>>> comma.
>>>>>
>>>>> --------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> §3.6:
>>>>>
>>>>>>    Adversaries can also attempt to hijack the traffic to the
>>>>>>    regular fronting server, using for example spoofed DNS 
>>>>>> responses or
>>>>>>    spoofed IP level routing, combined with a spoofed certificate.
>>>>> It's a bit unclear why this is described as part of the injection of
>>>>> a third party into the scenario. As far as I understand, the 
>>>>> described
>>>>> attack exists today, in the absence of any SNI encrypting schemes.
>>>>> If there's a new twist introduced by a multi-party security context,
>>>>> the current text doesn't seem to explain what it is.
>>>>>
>>>>> --------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> §3.7:
>>>>>
>>>>>>    Multiple other applications currently use TLS, including for 
>>>>>> example
>>>>>>    SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590].
>>>>> Nit: "...including, for example, SMTP..."
>>>>> Nit: "...and XMPP..."
>>>>>
>>>>>>    These applications
>>>>>>    too will benefit of SNI encryption.  HTTP only methods like those
>>>>>>    described in Section 4.1 would not apply there.
>>>>> Nit: "...benefit from SNI..."
>>>>> Nit: "HTTP-only..."
>>>>>
>>>>> --------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> §4.2:
>>>>>
>>>>>>    This requires a
>>>>>>    controlled way to indicate which fronting ferver is acceptable 
>>>>>> by the
>>>>>>    hidden service.
>>>>> Nit: "...server..."
>>>>>
>>>>> --------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> §7:
>>>>>
>>>>>>    Thanks to Stephen Farrell, Martin Rex Martin Thomson
>>>>>>    and employees of the UK National Cyber Security Centre for their
>>>>>>    reviews.
>>>>> I think you're missing a comma between the two Martins.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> TLS mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>