Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Salz, Rich]

>   A stable, publicly available document is basically an RFC.

Not always; ISO et al.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for consensus: Removing 0-RTT client auth

[Dan Harkins]

  Hi Sean & Joe,

On Tue, March 29, 2016 5:59 am, Sean Turner wrote:
> All,
>
> To make sure we’ve got a clear way forward coming out of our BA
> sessions, we need to make sure there’s consensus on a couple of
> outstanding issues.  So...
>
> It seems that there is a clear consensus not to support 0-RTT client
> authentication in TLS 1.3 at this time.  If you think 0-RTT client
> authentication needs to be supported please indicate so now and provide
> your rationale.

  I don't think it needs to be supported and would be happy if
it was removed. It's a dangerous and flawed feature. My concern
is that if (which I fear is pronounced "when") an exploit is found
it might be easy to remove in a browser update but there's gonna
be some large TLS concentrator vendor that'll have a helluva time
getting its deployed boxes patched and it'll be ugly.

  The rationale for this-- to get an ad to me just that much faster
(an ad, I note, that I sure hope my ad blocking software will prevent
me from seeing), and that the people who want to do this know what
they're doing so it'll all be fine (which is not reassuring in the
least)-- just does not justify the risk.

  regards,

  Dan.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0

[Yoav Nir]

> On 3 Apr 2016, at 8:44 AM, Martin Thomson  wrote:
> 
> On 3 April 2016 at 18:18, Peter Gutmann  wrote:
>> I think the reason why there's no rationale is because there's no rational
>> explanation for lumping TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 in with the likes
>> of TLS_RSA_EXPORT_WITH_RC4_40_MD5.
> 
> You evidently believe that a decision to move to AEAD only is
> irrational.  Others, myself included, do not.
> 

Agree. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 is fine if you also implement the 
EtM extension that nobody did. OTOH everybody implemented AES-GCM, so that’s 
better in the “yeah, we do that already” criterion. And as Dave McGrew’s draft 
showed us, you can fit CBC + HMAC into an AEAD in case you really, really like 
CBC and HMAC.

Yoav

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0

[Martin Thomson]

On 3 April 2016 at 18:18, Peter Gutmann  wrote:
> I think the reason why there's no rationale is because there's no rational
> explanation for lumping TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 in with the likes
> of TLS_RSA_EXPORT_WITH_RC4_40_MD5.

You evidently believe that a decision to move to AEAD only is
irrational.  Others, myself included, do not.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls