Re: [IPsec] WGLC on draft-ietf-ipsecme-rfc4307bis-11

[Tero Kivinen <[e-mail]>]

Paul Wouters writes:
> > Section 4.2
> >
> >       |  RSASSA-PSS with Empty Parameters   | MUST NOT |         |
> >       |  RSASSA-PSS with Default Parameters | MUST NOT |         |
> >
> > Well, I'm a confused with these requirements. As far as I
> > understand the RSASSA-PSS parameters default to using a SHA1 for
> > both hashAlgorithm and maskGenAlgorithm. Isn't more clear for
> > readers to include
> >
> >       |  RSASSA-PSS with SHA1            | MUST NOT    |         |
> >
> > instead of these two lines, which in their current form don't
> > explicitely refer to any cryptographic algorithm and force
> > reader to dig into RSASSA-PSS specification to just get
> > know that it was SHA1 meant? Or did I miss something?
> 
> I'll leave this one to Tero.

This is aligned with RFC7427, which has 3 examples for RSASSA-PSS. The
first one is RSASSA-PSS with empty parameters. This means signature
uses SHA-1 and it is MUST NOT. This is the one implementations
generate if they use default parameters. The second one is an example
with RSASSA-PSS with Default parameters explictly encoded. This is not
according to the DER, but RFC4055 still requires that implementations
need to understand it, even when generating they should be using the
Empty Parameters version, and it still uses SHA1 so it is also MUST
NOT. 

The 3rd example in RFC7427 is RSASSA-PSS with SHA-256, and that is
specified as MUST.

In the beginning of the 4.2 we already explictly specify levels for
hash functions, i.e. SHA1 is MUST NOT. The next table only lists the
version we have in the RFC7427 and which are not MAY. 

> >   AUTH_AES-XCBC is only recommended in the scope of IoT, as Internet of
> >   Things deployments tend to prefer AES based pseudo-random functions
> >   in order to avoid implementing SHA2. 
> >
> > s/AUTH_AES-XCBC/AUTH_AES-XCBC_96    (as in IANA Registry)
> 
> Actually, we should add this to section 9 for renaming and call it
> AUTH_AES_XCBC_96.

It is already called that in the IANA registry. I fixed the "-" to "_"
in the Berlin IETF, while talking to the IANA people for other things,
and when noticed that typo in registry.

So the IANA registry already says "AUTH_AES_XCBC_96" and that is what
we should use also in this document, or we can also talk about
AES-XCBC (without AUTH_ and _96), when we are talking about the
algorithm in general (like AES-GCM vs AES-CBC). In this case, I think
the AUTH_AES_XCBC_96 is correct one.
-- 
[e-mail]