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

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
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls