Re: [Cfrg] Elliptic Curves - signature scheme: friendliness to low memory implementations (ends on June 3rd)

[David Leon Gil <[e-mail]>]

> Finally, it should be noted that most of the security stuff in IETF
> protocols assume that signatures are "deteched" (TLS
> syntax even has a "macro" for that), and will not work with
> "sealed" signatures.

I'm curious what the issue is here? (Maybe I don't understand what you mean
by "sealed"...)

I'm also not sure why bad decisions from the past should be left
uncorrected: a history, however long, of poor design choices is not a
*reason* to continue to make them.

- dlg
On Fri, May 22, 2015 at 10:46 PM Ilari Liusvaara <
[e-mail]> wrote:

> On Sat, May 23, 2015 at 12:41:31AM -0000, D. J. Bernstein wrote:
>
> > How long are the messages that are actually signed in IETF protocols?
> > For the protocols where the answer is uncontrolled: Do implementations
> > allow messages that don't fit into memory? How do those implementations
> > avoid passing along unverified data? For PGP we know that the answer is
> > "They do pass along unverified data, and this is a security nightmare."
>
> I didn't quickly find list of IETF security protocols, but the only ones
> that come to mind that would need to handle "large" (potentially too much
> to store in memory) amounts of data are OpenPGP and CMS.
>
> Then some places deal with "medium" (annoying to store in memory) amounts
> of data, like TLS 1.0-1.2 client signatures and possibly something in
> IPSec (looked briefly at the RFC, can't quickly estimate the amount of
> data).
>
> Most of the rest should be "small" (small amounts of data, highly
> transient).
>
> The places that sign "medium" amount of data usually also fundamentially
> break the "signed message" model.
>
> Finally, it should be noted that most of the security stuff in IETF
> protocols assume that signatures are "deteched" (TLS syntax even
> has a "macro" for that), and will not work with "sealed" signatures.
>
>
> -Ilari
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>