On Sat, Oct 10, 2015 at 4:44 AM, Dave Garrett
wrote:
> There is one problem with the current proposed sentinel value,
> 0x030403040304. It limits what can be done with future versions. It's not
> as simple as just making that use 0x030503050305, because we want 1.3
> clients to be able to recogni
On Sat, Oct 10, 2015 at 7:37 PM, Dave Garrett
wrote:
> In light of completely unsurprising recent events [0], I think it's time
> to reconsider the current consensus on how to deal with SHA-1 in TLS 1.3.
> Currently, it's allowed if needed by servers that have nothing better [1].
To be clear, t
On Sat, Oct 10, 2015 at 07:44:04PM +0200, Eric Rescorla wrote:
> On Sat, Oct 10, 2015 at 7:37 PM, Dave Garrett
> wrote:
>
> > In light of completely unsurprising recent events [0], I think it's time
> > to reconsider the current consensus on how to deal with SHA-1 in TLS 1.3.
> > Currently, it's
On Sat, Oct 10, 2015 at 11:28:28PM +0300, Ilari Liusvaara wrote:
> > To be clear, the only thing that's allowed is SHA-1 in *certificates*.
> > It's forbidden in CertificateVerify.
>
> Isn't using it in certificates precisely more dangeous than using it in
> CertificateVerify (especially with TLS
On Saturday, October 10, 2015 04:28:28 pm Ilari Liusvaara wrote:
> On Sat, Oct 10, 2015 at 07:44:04PM +0200, Eric Rescorla wrote:
> > To be clear, the only thing that's allowed is SHA-1 in *certificates*.
> > It's forbidden in CertificateVerify.
>
> Isn't using it in certificates precisely more da
On Sat, Oct 10, 2015 at 08:59:08PM +, Viktor Dukhovni wrote:
> I don't want to see client's or servers hanging up just because a
> peer presents a SHA-1 chain that would have been simply ignored
> had it been SHA2-256 instead.
In particular pull request 287 breaks opportunistic TLS and *must*
On Saturday, October 10, 2015 04:59:09 pm Viktor Dukhovni wrote:
> So long as SHA-1 self-signatures are still tolerated in root or
> self-signed end-entity certificates, I have no objection to TLS
> 1.3 specifying that a certificate signed with SHA-1 is not trusted
> even when issued by a trusted i
On Sat, Oct 10, 2015 at 05:11:56PM -0400, Dave Garrett wrote:
> Note that opportunistic encryption is weird and getting
> the whole document to be perfect for it might not be entirely doable, as
> OE needs to tolerate more fuzziness than the main spec should allow.
Unfortunately requirements in t
On Saturday, October 10, 2015 05:19:30 pm Viktor Dukhovni wrote:
> On Sat, Oct 10, 2015 at 05:11:56PM -0400, Dave Garrett wrote:
> > Note that opportunistic encryption is weird and getting
> > the whole document to be perfect for it might not be entirely doable, as
> > OE needs to tolerate more fuz
On Sat, Oct 10, 2015 at 06:46:47PM -0400, Dave Garrett wrote:
> > Unfortunately requirements in the base TLS document end up "set in
> > stone" in software implementations, and then break opportunistic
> > TLS in ways application software can't work around.
>
> I do agree with rewording the text
On Saturday, October 10, 2015 10:35:16 pm Viktor Dukhovni wrote:
> This is not difficult, it just requires not forgetting that there's
> more than one way to do (or not do) authentication, and that the
> TLS protocol needs to remain largely agnostic of the authentication
> model. Just deliver the
On Sat, Oct 10, 2015 at 11:00:30PM -0400, Dave Garrett wrote:
> On Saturday, October 10, 2015 10:35:16 pm Viktor Dukhovni wrote:
> > This is not difficult, it just requires not forgetting that there's
> > more than one way to do (or not do) authentication, and that the
> > TLS protocol needs to re
On Sun, Oct 11, 2015 at 12:33:33AM -0400, Dave Garrett wrote:
> https://github.com/tlswg/tls13-spec/pull/287
>
> PR updated with some revisions. Please take a look at some point and tell me
> what you think.
Still problematic, by changing more text than necessary. The following
is wrong and sh
13 matches
Mail list logo
