Kathleen Moriarty writes:
>MD5 is not discussed in the current version of RFC7525.
I would add it, if this is guidance for general use then it should cover all
the bases, if SHA-1 is a MUST NOT then MD5 is a REALLY REALLY REALLY MUST NOT.
(Technically SHA-1 is still safe for ephemeral signing,
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : Exported Authenticators in TLS
Author : Nick Sullivan
Filename: draft-ietf-tls-expo
On Fri, May 3, 2019 at 4:09 PM Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:
>
>
> Sent from my mobile device
>
> On May 3, 2019, at 3:56 PM, Eric Rescorla wrote:
>
>
>
> On Fri, May 3, 2019 at 10:31 AM Peter Gutmann
> wrote:
>
>> Having said that, given an RFC saying MUST NOT 1.0
Sent from my mobile device
> On May 3, 2019, at 3:56 PM, Eric Rescorla wrote:
>
>
>
>> On Fri, May 3, 2019 at 10:31 AM Peter Gutmann
>> wrote:
>> Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what the
>> original discussion was about, why not also add MUST NOT MD5 and
On Fri, May 3, 2019 at 10:31 AM Peter Gutmann
wrote:
> Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what
> the
> original discussion was about, why not also add MUST NOT MD5 and SHA1 in
> TLS
> 1.2 to the text?
>
This seems like a reasonable proposal.
-Ekr
> Peter.
>
>
> On May 3, 2019, at 1:30 PM, Peter Gutmann wrote:
>
> Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what the
> original discussion was about, why not also add MUST NOT MD5 and SHA1 in TLS
> 1.2 to the text?
And perhaps MUST EtM, ... which starts to look a lot like "must TL
Benjamin Kaduk writes:
>I'll make the obligatory note that SHA-2 is fine
Sure, and that was the really strange thing with TLS 1.2, why not just say
SHA-2 or better only, rather than adding mechanisms that were much, much
weaker than its predecessors? So the simple fix is just to use SHA-2 only
On Fri, May 03, 2019 at 04:53:44PM +, Peter Gutmann wrote:
> Hubert Kario writes:
>
> >And the practical research:
> >https://eprint.iacr.org/2016/131.pdf
> >https://www.iacr.org/archive/asiacrypt2009/59120136/59120136.pdf
> >only confirms that.
>
> That would be the practical research that
Hubert Kario writes:
>And the practical research:
>https://eprint.iacr.org/2016/131.pdf
>https://www.iacr.org/archive/asiacrypt2009/59120136/59120136.pdf
>only confirms that.
That would be the practical research that says:
Due to these constraints, the practical impact of our second preimage
Hi,
the example handshake traces for TLS 1.3 (RFC8448) seems not to fully
comply to the TLS 1.3 standard (RFC8446).
RFC8446 in 4.2.3. says that an implementation must not offer deprecated
algorithms in the signature algorithms extension:
"In TLS 1.2, the extension contained hash/signature pairs.
On Friday, 3 May 2019 16:56:54 CEST Martin Rex wrote:
> Hubert Kario wrote:
> > We've been over this Martin, the theoretical research shows that for
> > Merkle- Damgård functions, combining them doesn't increase their security
> > significantly.
>
> You are completely misunderstanding the results
Hubert Kario wrote:
>
> We've been over this Martin, the theoretical research shows that for Merkle-
> Damgård functions, combining them doesn't increase their security
> significantly.
You are completely misunderstanding the results.
The security is greatly increased!
Nobody is afraid of the
On Thu, May 2, 2019 at 7:51 PM Martin Thomson wrote:
> Thanks Kathleen, these look like good changes.
>
> Nits in the proposed BCP195 section: Lose the "p" in mpost and s/off of/on/
>
Thank you, Martin!
>
> On Fri, May 3, 2019, at 01:12, Kathleen Moriarty wrote:
> > Thank you for your feedback
On Wednesday, 1 May 2019 01:49:52 CEST Martin Rex wrote:
> Martin Thomson wrote:
> > On Sat, Apr 27, 2019, at 07:29, Viktor Dukhovni wrote:
> >> The sound-bite version is: first raise the ceiling, *then* the floor.
> >
> > Yep. We've done the ceiling bit twice now.
> > Once in 2008 when we publi
14 matches
Mail list logo
