Subject: [dmarc-ietf] Section [5.2.1] of the ARC draft

From: Gene Shuman <[email-masked]>
Date: Wed, 18 Jan 2017 14:46:44 -0800

Hello,

This is something of a continuation of my other email wrt section [5.2.1]
of the draft.  I've discovered an even larger range of indeterminate cases
wrt to this section, and any attempt to rectify this within the given
framework seems to get fairly messy.  Basically, there is a large class of
input headers that aren't covered by the current language, and cant be
signed.

The basic problem is that for a large range of invalid messages, the notion
of arc set is not well defined.  The standard notion of arc set is all
fields with identical i= tag.  This notion breaks down when you have
violations such as duplicate i= values.  The only way we can recover our
notion of arc sets at this point is to define arc sets *logically* as
contiguous blocks of arc headers(AS, AMS, AAR) in the input emails.
Section [5.2.1] seems to be operating tacitly under this revised
definition, and given that the ordering it specifies makes sense.

However if we have further degeneracy wherein we can no longer logically
form arc sets, either because of missing or invalid i= values, or
intermixed/incomplete sets, the ordering in section is no longer
applicable, and we're left with a huge gap.

I think its clear that we fail all of these messages.  But for signing, we
need to specify an ordering on these pathological arc headers, as section
[5.2.1] only applies when you can logically define arc sets. We also
probably need this ordering to downgrade to that in section [5.2.1] when
applicable, and to the defacto ordering in the standard case.

The obvious solution here is to simply sign *all *arc headers under all
sealing/validation operations in a bottom up order, regardless of the
validity/ordering of the headers in the email.  Reasons that this is good:
- This is the simplest language
- This probably has the simplest implementations
- Assuming validly signed inputs this defaults to the ordering in section
[5.1.1.3]
- This also defaults to section [5.2.1], in the slightly less valid, but
still broken state, apart from the alphabetical ordering clause
-  I think this is basically what's implicitly intended throughout the
draft.

The only other way I can see to approach this issue is to continue down the
path of [5.2.1] and define an additional ordering on these pathological
cases.  It seems wrong to me to force implementors to provide whatever
weird sorting functionality this would be, just for the sake of signing
pathological examples, so I recommend against this approach.

So I think the universal bottom up ordering is the way to go.  Anybody have
any opinions here?  I'm happy to take the lead on proposing changes to the
draft.

Regards,
=Gene

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Jan 2017 15:05:31 -0800

On Wed, Jan 18, 2017 at 2:46 PM, Gene Shuman <[email-masked]> wrote:

> The only other way I can see to approach this issue is to continue down
> the path of [5.2.1] and define an additional ordering on these pathological
> So I think the universal bottom up ordering is the way to go.  Anybody
> have any opinions here?  I'm happy to take the lead on proposing changes to
> the draft.
>

This is also what I had in mind.  If I receive a bunch of ARC Sets that are
not all pristine at least in terms of being complete (exactly one of each
of the ARC header fields) and/or there are gaps in the instance sequence,
then the chain is de facto invalid and I should report it as such using
"cv=fail" when generating my own seal.  I suggest we don't even attempt the
crypto operations to verify any of the existing seals or AMS fields.

There's some history of being gentle or forgiving in the email space, and
it has never served us well.  (See RFC7103, for example.)  We shouldn't
subject ARC to such vagueries, especially when people are betting on it
solving a lot of problems.

-MSK

---

From: Kurt Andersen <[email-masked]>
Date: Thu, 19 Jan 2017 14:25:58 +0530

On Thu, Jan 19, 2017 at 4:35 AM, Murray S. Kucherawy <[email-masked]>
wrote:

>> I think its clear that we fail all of these messages.  But for signing,
>> we need to specify an ordering on these pathological arc headers, as
>> section [5.2.1] only applies when you can logically define arc sets. We
>> also probably need this ordering to downgrade to that in section [5.2.1]
>> when applicable, and to the defacto ordering in the standard case.
>>
>
The intent of section 5.2.1 was never to deal with pathological cases. It
was to deal with somewhat broken MTAs that do stupid things like reordering
headers in alphabetical order or slightly broken implementations which
might replicate headers.

I'm OK with a general approach of declaring all such broken implementations
as being "beyond redemption". We should probably focus on a clear way to
demarcate such a condition when it is processed by a conformant handler and
move on.

Gene, if you have wording suggestions in mind, those will be gratefully
received; otherwise I'll take a swing at restructuring the section while
I'm in flight on Saturday. One of the questions that comes to mind is "what
should the good actor do with all the pathological junk?" Should we specify
some sort of debridement handling?

Cheers,
  Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Jan 2017 07:32:22 -0800

> headers in alphabetical order or slightly broken implementations which
Reordering shouldn't be a problem for us because it's easy to search
through a relatively short list for an ARC field bearing a particular "i="
value.  If the only thing that ever happens is reordering, we should still
be fine (a la DKIM's "h" tag).

Duplication is arguably fine as long as the duplicate is identical to the
original, but I think once you have to go so far as to evaluate that, the
chain has actually been directly affected, and it's fine to give up.

-MSK

---

From: Gene Shuman <[email-masked]>
Date: Thu, 19 Jan 2017 11:46:29 -0800

OK great, I think we're on the same page.  Focusing on what good actors
should do with malformed arc sets is exactly the question.  If we do want
to keep them around & continue  the chain, making sure that we fail, I
still suggest the bottom up order for signing.  Stripping out the malformed
arc sets and restarting the chain, possibly with something like a new
CV_Invalid is another possibility.  This is an interesting idea, that I
think I like, but do we suspect we would be removing information that
somebody might find useful?

Regards,
=Gene

---

From: Gene Shuman <[email-masked]>
Date: Thu, 19 Jan 2017 11:48:07 -0800

Or maybe we even continue the chain with a cv=CV_Invalid, which implies
that b= is empty or missing as it can't be generated.

On Thu, Jan 19, 2017 at 11:46 AM, Gene Shuman <[email-masked]> wrote:

>>> The intent of section 5.2.1 was never to deal with pathological cases.
>>> It was to deal with somewhat broken MTAs that do stupid things like
>>> reordering headers in alphabetical order or slightly broken implementations
>>> which might replicate headers.
>>>
>>>

---

From: Kurt Andersen <[email-masked]>
Date: Fri, 20 Jan 2017 07:48:28 +0530

> chain has actually been directly affected, and it's fine to give up.

Gene's suggestions (omitted from this due to top posting) about creating a
new "invalid" CV tag value seems like a reasonable response to a badly
broken (structurally) ARC chain. Since we are _a priori_ only interested in
good chains I don't think that adding this creates any exploits for bad
actors since a malicious intermediary can destroy/corrupt/etc an ARC chain
any which way.

I'm more concerned about pathologies that could be introduced in the quest
to affix an ARC set with i=(previous + 1) when the "previous" value is
malicious (not a number, too big a number, etc). In some sense, we almost
need an "end of chain, don't waste your time any further" signal.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 20 Jan 2017 14:23:48 -0500

> need an "end of chain, don't waste your time any further" signal.

I'm not on the ARC list, so I'll pile on this thread here...

I understand the minimum key size in the draft is 512 bits.  I'm not planning 
on releasing any software that supports key sizes less than 1024, so I 
guarantee you interoperability problems for small keys.

For those that may have forgotten, I'll pass on a reminder of how well 512 bit 
keys work even half a decade ago:

https://www.wired.com/2012/10/dkim-vulnerability-widespread/

Scott K

---

From: Gene Shuman <[email-masked]>
Date: Fri, 20 Jan 2017 11:46:23 -0800

Kurt, I think terminating the chain with a cv=invalid is a good approach.
The general idea being that if there is any seal found with cv=invalid then
validation fails & we don't continue the chain.  When a good intermediary
finds an invalid chain, a seal is affixed(no need for AMS, or AAR), with
the cv=invalid value.  Im assuming we no longer require the a,b,d,s tags at
this point, as they're irrelevant.  Or do we even want to consider having a
4th type of header field(ARC-ChainInvalid?), possibly with identifying or
failure information, just so were not modifying AS too much? Are there any
security concerns with either of these approaches that need to addressed?

An open question then is what constitutes an invalid set.  I would suggest
that only the cases of duplicated or malformed/invalid i= values are
invalid sets.  Missing/incomplete sets fail, and mis-ordered sets are
handled normally.

+++1 wrt Scott's comment about 512 bit keys.  We inherit this requirement
from the DKIM spec, but imho it is not reasonable.  If this is worth
discussing, perhaps we should move it to another thread?

Regards,
=Gene

On Fri, Jan 20, 2017 at 11:23 AM, Scott Kitterman <[email-masked]>
wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Steven M Jones <[email-masked]>
Date: Fri, 20 Jan 2017 11:58:08 -0800

> I'm not on the ARC list, so I'll pile on this thread here...

This is the right place for anything constructive regarding the
specification, so no problem regarding any other lists.

> guarantee you interoperability problems for small keys.

+1 -- no need for weak keys.

1) Do we have a normative reference within the RFC framework for key
lengths for different crypto systems, and can we simply invoke that
reference rather than including a hard figure in this spec?

2) Does such a reference still consider 1k keys as acceptable at this
time? Is there a schedule for periodic review?

--S.

---

From: "John Levine" <[email-masked]>
Date: 20 Jan 2017 22:17:02 -0000

>reference rather than including a hard figure in this spec?

There's RFC 3766, but it's over a decade old and has rules for how to
figure out how long a key you need, not the actual sizes.

This NIST publication seems relevant:

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf

The tables on pages 52 and 53 suggest that we use 2K keys and sha256 hashes.

>time? Is there a schedule for periodic review?

No.  See the document.

R's,
John

---

From: Kurt Andersen <[email-masked]>
Date: Sun, 22 Jan 2017 05:42:49 +0530

On Jan 20, 2017 11:23, "Scott Kitterman" <[email-masked]> wrote:

I understand the minimum key size in the draft is 512 bits.

There is nothing in the ARC spec about key sizes.

--Kurt

---

From: Peter Goldstein <[email-masked]>
Date: Sat, 21 Jan 2017 16:39:36 -0800

>From the ARC spec:

5.3 <https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-01#section-5.3>.
Key Management and Binding

   The public keys for ARC header fields follow the same requirements
   and semantics as those for DKIM-Signatures, described in Section 3.6
   of [RFC6376] <https://tools.ietf.org/html/rfc6376#section-3.6>.
Operators may use distinct selectors for the ARC
   header fields at their own discretion.

>From the DKIM spec (RFC 6376)

3.3.3 <https://tools.ietf.org/html/rfc6376#section-3.3.3>.  Key Sizes

   Selecting appropriate key sizes is a trade-off between cost,
   performance, and risk.  Since short RSA keys more easily succumb to
   off-line attacks, Signers MUST use RSA keys of at least 1024 bits for
   long-lived keys.  Verifiers MUST be able to validate signatures with
   keys ranging from 512 bits to 2048 bits, and they MAY be able to
   validate signatures with larger keys.  Verifier policies may use the
   length of the signing key as one metric for determining whether a
   signature is acceptable.

and

3.3 <https://tools.ietf.org/html/rfc6376#section-3.3>.  Signing and
Verification Algorithms

   DKIM supports multiple digital signature algorithms.  Two algorithms
   are defined by this specification at this time: rsa-sha1 and rsa-
   sha256.  Signers MUST implement and SHOULD sign using rsa-sha256.
   Verifiers MUST implement both rsa-sha1 and rsa-sha256.

While admittedly the ARC RFC points to a different section of RFC 6376
(3.6), the statement beginning of section 5.3 certainly reads like it
inherits public key requirements and semantics from the DKIM RFC.  The DKIM
RFC explicitly requires verifiers to validate signatures with bit sizes
ranging from 512 bits to 2048 bits.

If the key sizes recommendation is not intended to be inherited from RFC
6376, then that should probably be explicitly called out and the
appropriate key guidelines defined.

Best,

Peter

-- 

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

[email-masked]
+1.415.793.5783

---

From: Kurt Andersen <[email-masked]>
Date: Sun, 22 Jan 2017 12:30:14 -0800

On Sat, Jan 21, 2017 at 4:39 PM, Peter Goldstein <[email-masked]> wrote:

>
> . . . ARC . . . inherits . . . from the DKIM RFC.  The DKIM RFC explicitly
> requires verifiers to validate signatures with bit sizes ranging from 512
> bits to 2048 bits.
>
> There is a separate effort going on in the context of the UTA working
group to address technologically obsolete encryption strength
recommendations that have appeared over time in a variety of different
RFCs. I don't think that adding yet another independent reference is a good
idea and I am strongly opposed to trying to torque the ARC requirements to
be different from DKIM.

If Scott is planning to make dkimpy non-conformant to the DKIM spec, I
think that is regrettable, but I don't see that making the problem worse
with ARC "going its own way" helps anyone.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 22 Jan 2017 21:18:08 +0000

>with ARC "going its own way" helps anyone.

No responsible operator has used the RFC minimum DKIM key sizes for a long time. They were trivial to bypass half a decade ago.  No one has ever complained about 1024 bits default minimum being too big.  I did once get a complaint about the Debian opendkim package suggesting the minimum should be 2048 bits.

Maybe some other working group will accomplish something someday is not a good reason to perpetuate obsolete crypto in this one.

Scott K

---

From: Kurt Andersen <[email-masked]>
Date: Sun, 22 Jan 2017 13:46:53 -0800

On Sun, Jan 22, 2017 at 1:18 PM, Scott Kitterman <[email-masked]>
wrote:

> No responsible operator has used the RFC minimum DKIM key sizes for a long
> time. They were trivial to bypass half a decade ago.  No one has ever
> complained about 1024 bits default minimum being too big.  I did once get a
> complaint about the Debian opendkim package suggesting the minimum should
> be 2048 bits.
>
> Maybe some other working group will accomplish something someday is not a
> good reason to perpetuate obsolete crypto in this one.
>
> Scott K
>

Don't you think it would be better to "fix" the DKIM spec than to have ARC
"do its own thing"?

--Kurt

---

From: Kurt Andersen <[email-masked]>
Date: Sun, 22 Jan 2017 13:48:28 -0800

On Sun, Jan 22, 2017 at 1:18 PM, Scott Kitterman <[email-masked]>
wrote:

> >think that is regrettable, but I don't see that making the problem
> >worse with ARC "going its own way" helps anyone.
> >
> >--Kurt
>

I agree with your points, but don't you think it would be better to "fix"
the DKIM spec than to have ARC "do its own thing" which does not address
the weakness still enshrined in the DKIM spec?

--Kurt

---

From: Peter Goldstein <[email-masked]>
Date: Sun, 22 Jan 2017 14:25:44 -0800

Kurt,

I agree that the best approach would be to update the DKIM spec to reflect
modern cryptographic realities.

I actually broached this topic on the IETF DKIM mailing list a couple of
months ago.  The thread quickly evolved into a discussion about using even
shorter key sizes (768 bit) to avoid the long term verifiability of emails,
and address associated privacy concerns.  There did not seem to be a lot of
support for raising the bit size requirements.  That said, perhaps others
would have more success.

If we can drive this change to RFC 6376, that would be great.  If not, I
think it's important that we make appropriate cryptographic recommendations
for ARC.  Not only because of the security implications, but also because I
can't imagine that ISPs that don't currently accept DKIM keys smaller than
1024 bits (e.g. Google) will accept ARC signatures with such keys.  It
needs to be made clear somewhere - the RFC, the usage guide, wherever -
that 512 bit keys just won't work.  There's a similar issue around the use
of SHA-1.

How would you suggest we drive a revision to RFC 6376 to address this issue?

Thanks.

Best,

Peter

On Sun, Jan 22, 2017 at 1:48 PM, Kurt Andersen <[email-masked]> wrote:

>> No responsible operator has used the RFC minimum DKIM key sizes for a
>> long time. They were trivial to bypass half a decade ago.  No one has ever

-- 

Bringing Trust to Email

[email-masked]
+1.415.793.5783

---

From: "John Levine" <[email-masked]>
Date: 22 Jan 2017 23:42:33 -0000

In article <CABuGu1r-Q2YejZLehQVp95spknZ0seEyJ8Op+Pvj8hiU=[email-masked]> you write:
>> complained about 1024 bits default minimum being too big. ...

>the weakness still enshrined in the DKIM spec?

Only if we want to stall ARC for a couple of years while we have
unproductive arguments about what it means to update the DKIM spec and
whether key lengths are the only thing we want to twiddle.

While ARC signatures are a lot like DKIM signatures, they're not DKIM
signatures.  A spec that says "ARC signatures are created the same way
as DKIM signatures except that keys MUST be at least 1024 bits" is no
harder to implement than one that says they're just the same, and is
likely to match what people do in practice anyway.

I looked at the current version of dkimpy (0.5.6) and found that by
default it requires a minimum key length of 1024 which you can
override with a larger or smaller size if you want.  If Scott says
nobody's ever complained about it, I believe him.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 22 Jan 2017 23:49:22 +0000

On January 22, 2017 4:48:28 PM EST, Kurt Andersen <[email-masked]> wrote:
>> >On Sat, Jan 21, 2017 at 4:39 PM, Peter Goldstein
><[email-masked]>
>> >wrote:
>> >
>> >>
>> >> requires verifiers to validate signatures with bit sizes ranging
>from
>> >512
>> >> bits to 2048 bits.
>> >>
>> >RFCs. I don't think that adding yet another independent reference is
>a
>> >good
>> >idea and I am strongly opposed to trying to torque the ARC
>requirements
>> >to
>> >be different from DKIM.
>> >
>long

In theory, sure.  In practice it's just a variation on waiting for someone else to do the work.  Additionally, DKIM will have an added burden of gaining community consensus that the security benefits of the change are important enough to break backward compatibility over.

This is not a kind of decision the IETF is great at getting done with any rapidity.

ARC, on the other hand, has no backward compatibility legacy to get caught by, unless we screw it up now.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 23 Jan 2017 01:28:45 -0000

>How would you suggest we drive a revision to RFC 6376 to address this issue?

As you saw, anything in the IETF that smells of crypto tends to go
into the weeds with the crypto fad du jour.

If you want to do this, I'd suggest an update with a very small focus:

1) Add a new signature algorithm, probably ECDSA, since it has good
support in OpenSSL.

2) Deprecate 512 and 1024 bit DSA keys, and recommend 2K bit DSA or
320 bit ECDSA keys.

The reason for ECDSA is that the keys are much smaller.  A 160 bit
ECDSA key is about as strong as a 1024 bit DSA key, so the equivalent
of a 4K DSA key is only 640 bits and will fit easily into a single TXT
record string.

Make it clear that the scope of this update is only the crypto, so
we can more easily chase away people who want DKIM to do something
it doesn't.  

R's,
John

PS: Although it would be entirely appropriate to ask them "where were
you when we were writing the last two specs?" people tend not to
respond well.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 23 Jan 2017 03:17:44 +0000

>idea and I am strongly opposed to trying to torque the ARC requirements

FYI, I did go review the UTA charter and anything DKIM related is out of scope for that working group.  It's limited to TLS.

Scott K

>worse

---

From: Brandon Long <[email-masked]>
Date: Sun, 22 Jan 2017 22:02:00 -0800

I don't think I see the point.

If the chain is invalid, it's invalid.  Your local AuthRes header can say
arc=fail.  If you forward, you can either strip the invalid chain or leave
it as is, any other receiver will also quickly determine the chain is
invalid.

Trying to figure out some signing order for pathological cases seems
unnecessary.

What's the point of passing my failure status on?

Brandon

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jan 2017 02:31:45 -0800

> modern cryptographic realities.

I'd like to come up with something better than updating DKIM every time
there's new advice on key sizes, etc.  Doing one update that points to the
best current advice, and then letting that other thing get updated
whenever, would be better.  Otherwise at some point we'll need to update
DKIM and ARC, and then DKIM, ARC, and the next thing, etc. etc.

But is there such a reference?

> support for raising the bit size requirements.  That said, perhaps others

I'd do an "updates" draft, but I'd like to resolve the above question first.

> How would you suggest we drive a revision to RFC 6376 to address this

On ietf-dkim, not here.  :-)

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jan 2017 02:41:31 -0800

> complaint about the Debian opendkim package suggesting the minimum should

As I recall there are issues using keys bigger than 1024 bits because
construction and/or correct interpretation of TXT records that contain keys
of that size or bigger has been problematic due to DNS provisioning
software that does the former wrong and DKIM verifiers that do the latter
wrong.  To my knowledge, nobody has ever shown evidence that the larger
keys are too computationally expensive to be used, or that any of the other
things mentioned in Section 3.3.3 of RFC6376 are actually a problem.

If we can nail those issues down, I think a lot of the practical resistance
goes away, and ARC can easily say ">= 1024" or whatever we want and be done
with it.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jan 2017 02:43:35 -0800

> Don't you think it would be better to "fix" the DKIM spec than to have ARC
I would argue that we're not chartered to update DKIM for this purpose,
though I'm happy to do that as an individual submission if we can get
consensus on what it should say.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jan 2017 02:45:03 -0800

On Sun, Jan 22, 2017 at 3:49 PM, Scott Kitterman <[email-masked]>
wrote:

>
> In theory, sure.  In practice it's just a variation on waiting for someone
> else to do the work.  Additionally, DKIM will have an added burden of
> gaining community consensus that the security benefits of the change are
> important enough to break backward compatibility over.
>
>
Actually that didn't come up on the ietf-dkim thread Peter referenced at
all.  I don't imagine that by itself would be an issue.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 23 Jan 2017 15:07:38 -0000

>What's the point of passing my failure status on?

I agree.  We don't have legacy code to work around, so we should
concentrate on getting things to work correctly.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Mon, 23 Jan 2017 07:39:52 -0800

> On Jan 23, 2017, at 2:41 AM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> As I recall there are issues using keys bigger than 1024 bits because construction and/or correct interpretation of TXT records that contain keys of that size or bigger has been problematic due to DNS provisioning software that does the former wrong and DKIM verifiers that do the latter wrong.  To my knowledge, nobody has ever shown evidence that the larger keys are too computationally expensive to be used, or that any of the other things mentioned in Section 3.3.3 of RFC6376 are actually a problem.

Yup.

> If we can nail those issues down, I think a lot of the practical resistance goes away, and ARC can easily say ">= 1024" or whatever we want and be done with it.

Fixing the DNS provision software everywhere isn't going to be trivial (and there's even a slight question of what fixing it means - a TXT record contains multiple strings and that DKIM concatenates them into a single one is a DKIM thing, not a DNS TXT thing). Continuing to push for that is a good thing, but it's going to take time.

But fixing that isn't required for 1024 bit keys and I don't see any good reason not to say ">= 1024 bits" today.

Cheers,
  Steve

---

From: "John Levine" <[email-masked]>
Date: 23 Jan 2017 15:49:28 -0000

>But is there such a reference?

I'm pretty sure there isn't.

Having checked with Paul Hoffman last night, I have a slightly different
version of the suggestion I made.

The first is that ARC says that keys SHOULD be 2K and MUST be at least
1K.  We understand the only likely deviation from the SHOULD to be due
to DNS crudware that can't provision larger keys.  Given the short
lifetime of ARC signatures, this is cryptographically defensible.

The second is to add a more modern signing algorithm.  Paul suggests
EdDSA with the ED25519 profile.  It was designed by well-known
civilian cryptographers with no help from the NSA, and there is a high
quality reference implementation that everyone likes.  A 256 bit EdDSA
key is about as strong as a 3000 bit RSA key and the crypto operations
are faster, so that's the last signing algorithm we're likely to need.

For coding purposes, the minimum key size is just a parameter, and I
would be astonished if changing the key size added as much as two
lines of code to the implementations.  Changing algorithms turns out
not to be much harder -- the DKIM or ARC application calls signing and
verification routines from a crypto library, and a different algorithm
just means calling a different routine.

A practical issue is that the most popular crypto library, OpenSSL,
hasn't added EdDSA yet.  They're currently on 1.0.2, and say it's
supposed to be in 1.1.1 which will be released when it's released.
So I'd suggest adding EdDSA to the spec, but not expect people to
implement it yet.  Then we can back-port the change into DKIM with
what I hope would be a two-page update.

This suggests a tweak to the ARC spec that we should make anyway.  The
way you do an algorithm migration, like the one we did from rsa-sha1
to rsa-sha256 is to put two signatures on the message for a while, one
with the old algorithm and one with the new one.  So a validator
ignores signatures with algorithms it doesn't understand, and if there
are two valid signatures with the same i=N using different algorithms,
just pick one.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 23 Jan 2017 15:52:06 -0000

>wrong.

I entirely believe that the provisioning crudware gets it wrong, but I
haven't heard of verifiers that don't handle multiple TXT strings.

Are you thinking of any specific ones?

I also agree that none of the other alleged issues are issues,
although I still think that migrating to EdDSA would be a good idea.

R's,
John

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 23 Jan 2017 07:59:36 -0800

On Mon, Jan 23, 2017 at 7:49 AM, John Levine <[email-masked]> wrote:

> 1K.

OK, I'm convinced. I'll add that info in and also update the usage doc with
additional explanation.

> are two valid signatures with the same i=N using different algorithms,

This sounds like something that we should definitely add so that there is
clarity, but it does add a situation where cv=unknown might happen if the
previous step only signed with an algorithm that was not understood.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 23 Jan 2017 16:05:04 +0000

>Are you thinking of any specific ones?

In the context of SPF, this has been an occasional problem.  Despite RFC 7208 (and RFC 4408 and I think all the non-IETF specs that came before) specifically specifying that multiple TXT strings should be concatenated, I've seen cases where some implementation insisted a space be added between the strings.

It's been awhile since I've seen this, so it may not be a problem anymore.  There is no obviously correct thing that someone won't screw up.

It's probably better to specify how to put multiple strings together.  RFC 7208 has words that can probably be reused without modification.

Scott K

---

From: "John R Levine" <[email-masked]>
Date: 23 Jan 2017 11:12:48 -0500

> previous step only signed with an algorithm that was not understood.

Right -- you can't tell a signature with an unknown algorithm with one 
that's just fake.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Peter Goldstein <[email-masked]>
Date: Mon, 23 Jan 2017 09:08:47 -0800

> lifetime of ARC signatures, this is cryptographically defensible.

+1, with the suggested modification that ARC says that keys SHOULD be 2K or
larger.

Verifiers should be required to support keys from 1024 bits up to some
larger value like 4096 bits, to give some future proofing for anyone who
really, really wants to use RSA.   As John notes, there's not much
difference between handling 2K, 4K, or 8K keys from an implementation
standpoint.

> are faster, so that's the last signing algorithm we're likely to need.

I strongly support the idea of adding a more modern signing algorithm as
part of ARC (and ideally eventually backport support to DKIM).  RSA and DSA
are no longer state of the art.  The specific suggestion he conveys from
Paul (EdDSA with the ED25519 profile) sounds in line with current best
practices, and is widely used and supported (
https://ianix.com/pub/ed25519-deployment.html).  And the smaller key size
obviously helps mitigate the broader DNS TXT record length concern.

> are two valid signatures with the same i=N using different algorithms,

+1

Best,

Peter

-- 

Bringing Trust to Email

[email-masked]
+1.415.793.5783

---

From: Matt Simerson <[email-masked]>
Date: Mon, 23 Jan 2017 09:50:02 -0800

> On Jan 23, 2017, at 7:49 AM, John Levine <[email-masked]> wrote:
> 
>> whenever, would be better.

Yes. Thank you. Yes.

>> Otherwise at some point we'll need to update
> I'm pretty sure there isn’t.

https://www.keylength.com/en/

Use this site to determine what cipher suite and key length you need to meet [NIST/ANSSI/IAD-NSA/…BSI] minimum level of security. 

See also: https://wiki.mozilla.org/Security/Server_Side_TLS from the fine folks at https://cipherli.st. It’s a list of ciphers and key lengths that have no known (public) vulnerabilities. For at least the past few years, it has been kept impeccably up-to-date.

> lifetime of ARC signatures, this is cryptographically defensible.

Given the half-life of IETF documents, I think this advice is still prey to the “that cipher suite / key length isn’t secure any more” problem as the existing documents. Instead, I think something like this is more appropriate:

	Keys SHOULD meet the minimum NIST and/or BSI recommendations (see https://www.keylength.com/). In 2017, the minimum bit length for factoring modulus keys is 2048, for elliptical curve is 256 and for hashes (SHA-*) is 256.

The minimum numbers are stated and their shelf life is implied. To be secure after 2017, implementers will have to do a little bit of homework to look up key lengths, but that’s really no different than before. At least now we’re providing a reference.

We should recommend secure defaults and let users of DNS crudware harangue their vendors or find new ones that can support publishing secure keys. We’re also foreshadowing long key lengths next year.

> EdDSA with the ED25519 profile.

+1

> It was designed by well-known

LOL. EC is currently quite robust but let’s not forget that we are but one novel new attack away from those faster crypto operations becoming a liability. Then we’ll all be jacking up our EC key lengths to compensate.

Matt

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 23 Jan 2017 13:39:03 -0500

> OK, I'm convinced. I'll add that info in and also update the usage doc with

In case you want a reference, I just rediscovered this:

http://www.kb.cert.org/vuls/id/268267

That's, I believe, where the current minimum comes from.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 23 Jan 2017 18:55:23 -0000

>We should recommend secure defaults and let users of DNS crudware harangue their vendors or find new ones that
>can support publishing secure keys. We’re also foreshadowing long key lengths next year.

Having been dealing with the crudware argument for a very long time* I
can tell you that the chances of getting all the crudware fixed
anytime soon are negligible, and nobody's going to change registrars
because they can't publish 2K keys.

That's why I suggested we add EdDSA.  It's, ah, crudware resistant.

R's,
John

* - see  draft-levine-dnsextlang-09

---

From: "John Levine" <[email-masked]>
Date: 23 Jan 2017 18:58:52 -0000

>reused without modification.

Might as well use section 3.6.2.2. from RFC 6376, since the ARC keys
are so similar to DKIM keys.

I don't ever recall hearing about this problem with DKIM.  I've been
publishing multi-string keys for years and never had reports of
breakage.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jan 2017 22:36:28 -0800

On Mon, Jan 23, 2017 at 9:50 AM, Matt Simerson <[email-masked]> wrote:

>
> LOL. EC is currently quite robust but let’s not forget that we are but one
> novel new attack away from those faster crypto operations becoming a
> liability. Then we’ll all be jacking up our EC key lengths to compensate.
>

The last time I broached the topic of adding EC to DKIM, I was told there's
no way that could proceed because EC was heavily encumbered by IPR claims.
Is that no longer the case?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jan 2017 22:38:33 -0800

On Mon, Jan 23, 2017 at 10:58 AM, John Levine <[email-masked]> wrote:

> >It's been awhile since I've seen this, so it may not be a problem
> anymore.  There is no obviously correct
> >thing that someone won't screw up.
> >
> >It's probably better to specify how to put multiple strings together.
> RFC 7208 has words that can probably be
> >reused without modification.
>

It's been a long time since I've seen this problem in either the DKIM or
SPF contexts (or any other), but it has happened, especially ten-ish years
ago when they were both much younger.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2017 19:44:14 -0000

>Is that no longer the case?

RFC 7479 adds Ed25519 to SSH and has no IPR disclosures.

Dan Bernstein is the primary author of Ed25519 and he's said it has no
patent problems:

https://cr.yp.to/ecdh/patents.html

R's,
John

---

From: Brandon Long <[email-masked]>
Date: Tue, 24 Jan 2017 15:44:49 -0800

> ago when they were both much younger.

We went to 2048 bit keys in 2012, after doing some tests (and being at 1536
for a bit), but haven't had any reported problems.  I think people who care
about DKIM will fix what they need to, not sure if ARC will be more widely
used than DKIM.

I'm not opposed to requiring support for different encryption algorithms,
but we really need to clean up and understand exactly how we handle
migration to a new algorithm, probably with a section in the draft specific
to it with an example.

Brandon

---

From: "John R Levine" <[email-masked]>
Date: 24 Jan 2017 18:51:20 -0500

> migration to a new algorithm, probably with a section in the draft specific

Fortunately, we have experience migrating from SHA1 to SHA256 hashes with 
DKIM.

Basically, as soon as you have support for the new algorithm, you start 
signing with both old and new.  After a while (likely a year or more) you 
try dropping the old signatures and see if your verification rates drop. 
I'd think that DMARC reports would be useful here.  Eventually the 
verification rates are close enough that you stop using the old algorithm.

Regards,

---

From: Peter Goldstein <[email-masked]>
Date: Wed, 25 Jan 2017 07:42:13 -0800

And as a timely item on this topic, RFC 8032 (Edwards-Curve Digital
Signature Algorithm) was just published -
https://tools.ietf.org/html/rfc8032
It was specifically published to facilitate adoption in the Internet
community.  The RFC makes no mention of any IPR claims as far as I can tell
from a quick read.

Best,

Peter

-- 

Bringing Trust to Email

[email-masked]
+1.415.793.5783

---

From: Brandon Long <[email-masked]>
Date: Wed, 25 Jan 2017 10:39:53 -0800

On Jan 24, 2017 3:51 PM, "John R Levine" <[email-masked]> wrote:

Sure, with dkim. With arc, it's a bit more complicated, we need to
understand exactly how to sign the chain if there are multiple AMS and AS
headers.  We probably want text about what happens if only one verifies as
well, and whether a hop should continue signing both paths or just one.

Brandon

---

From: Paul Rock <[email-masked]>
Date: Wed, 25 Jan 2017 14:57:45 -0500

I see a rabbit hole here... So you're transitioning, so you sign twice (one
with your old, one with your new) before you send to me.... and hey, I'm
not the end point either, so I need to forward it along, but I'm also
transitioning, so I sign both of yours, twice? I would kind of have to,
wouldn't I? as I have no idea what downstream supports before I send to the
next hop...

-- 
PAUL ROCK
Principal Software Engineer | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305

---

From: "John R Levine" <[email-masked]>
Date: 25 Jan 2017 20:26:24 -0500

> well, and whether a hop should continue signing both paths or just one.

All quite reasonable.

Only one verifies: that's fine, the other is likely an algorithm you don't 
handle (yet).  This is inherited from DKIM, a broken signature is the same 
as no signature and doesn't imply anything bad.

What to sign: just one.  It occurs to me that this is kind of fragile, 
since if you just sign one, it has to be the one that is farther down. 
I'm wondering if we should suggest that if there are two signatures for 
the same thing, discard the one you didn't use.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 25 Jan 2017 20:27:43 -0500

> wouldn't I?

No, you just sign one.  See the previous message.

We might as well figure this out now, because even if we only have one 
signing alg and one hash alg now, sooner or later we'll have to add other 
ones.

R's,
John

---

From: Brandon Long <[email-masked]>
Date: Wed, 25 Jan 2017 18:07:03 -0800

> signing alg and one hash alg now, sooner or later we'll have to add other

Signing one seems wrong, ie if the arc-seal only signs a single
arc-message-signature at a given hop, then the other signature can't be
verified, and if I can't handle the algorithm of the one that's covered,
then I can't verify the chain.

WIth AMS, we have an h header, so theoretically you'd just include the
multiple headers and h= ordering takes over.

The problem is for the Arc-Seal header where the h field is implicit, we'd
need to have a sort order for each AMS and AS header within a hop.  It
could be the order in the headers, it could be sort order by the algorithm
field, or something else.

Brandon

---

From: "John R Levine" <[email-masked]>
Date: 25 Jan 2017 23:23:33 -0500

> then I can't verify the chain.

Currently away on a trip, I'll take a closer look when I get home this 
weekend and see if I can make a clearer proposal.

R's,
John