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

[Christian Huitema <[e-mail]>]

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
>>